Identifying and Resolving Discrepancies Between Purchase Documents and Invoices

ABSTRACT

In an embodiment, a computer-implemented method operating at a server system is disclosed. The server hosts and electronic procurement system. In response to receiving an invoice, a purchase document corresponding to the invoice is identified. Contents of the purchase document are compared to contents of the invoice. A discrepancy is identified between the purchase document and the invoice. A notification is generated based upon the identified discrepancy. Related methods and systems are also disclosed.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.12/283,277, “Identifying and Resolving Discrepancies Between PurchaseDocuments and Invoices” filed on Sep. 9, 2008, which is acontinuation-in-part of U.S. patent application Ser. No. 12/007,815,“Procurement System and Method Over a Network Using a Single InstanceMulti-Tenant Architecture,” filed on Jan. 15, 2008, and U.S. patentapplication Ser. No. 12/283,277 claims the benefit and priority of U.S.Provisional Patent Application Ser. No. 61/130,028, filed on May 27,2008. All above-identified patents and patent applications are herebyincorporated by reference in their entireties.

This application is related to U.S. patent application Ser. No.10/318,814, filed Dec. 13, 2002, now U.S. Pat. No. 6,944,613 entitled“Method and System for Creating a Database and Searching the Databasefor Allowing Multiple Customized Views, issued on Sep. 13, 2005, whichis hereby incorporated entirely herein by reference.

This application is related to U.S. patent application Ser. No.12/283,276, “Taxonomy and Data Structure for an Electronic ProcurementSystem” filed on the same date as this application, which is herebyincorporated entirely herein by reference.

This application is related to U.S. patent application Ser. No.12/283,275 “Shopping Cart Management in an Electronic ProcurementSystem” filed on the same date as this application, which is herebyincorporated entirely herein by reference.

This application is related to U.S. patent application Ser. No.12/283,274, “Workflow and Material Management in an ElectronicProcurement System” filed on the same date as this application, which ishereby incorporated entirely herein by reference.

This application is related to U.S. patent application Ser. No.12/283,279, “Multi-Currency Normalization In An Electronic ProcurementSystem” filed on the same date as this application, which is herebyincorporated entirely herein by reference.

This application is related to U.S. patent application Ser. No.12/283,280, “Form Management In An Electronic Procurement System” filedon the same date as this application, which is hereby incorporatedentirely herein by reference.

This application is related to U.S. patent application Ser. No.12/283,278, “Providing Substitute Items When An Ordered Item IsUnavailable” filed on the same date as this application, which is herebyincorporated entirely herein by reference.

This application is related to U.S. patent application Ser. No.12/283,281, “Prioritizing Order And Receipt Of Items Between Users”filed on the same date as this application, which is hereby incorporatedentirely herein by reference.

This application is related to U.S. patent application Ser. No.12/283,282, “Invoice Workflow” filed on the same date as thisapplication, which is hereby incorporated entirely herein by reference.

FIELD OF INVENTION

The present invention relates generally to the field of procurement and,in particular, to a system and method for customized searching,procurement, data modeling, and order processing over a network using asingle instance system that supports multi-tenants in a multi-businessto multi-consumer type environment.

BACKGROUND OF INVENTION

Current e-commerce systems and methods provide consumers and businessesthe ability to browse product lines and consummate sales transactions.However, current e-commerce systems do not allow for easy customizationof the needed functionality to facilitate the transaction. While currentsystems can be customized for a specific business or customer, thecustomization is a time consuming and complicated task. Thesecustomizations must generally be hard coded into the application by thedevelopers, thereby incurring increases in costs, delay inimplementation, and loss of productivity. In the field of procurement,for example, an organization in need of a product or service generallyhas contractual relationships with multiple vendors to provide thedesired product or service. The contractual relationship may define suchterms as price, lot size, form of delivery, amount of discount, andother business rules. These rules may become complex as one term mayinfluence other terms, such as different levels of discounts based onthe number of items ordered.

Procurement systems also generally require order authorization from aprocurement officer of the organization or someone in charge ofreviewing the orders for compliance with internal policies of theorganization, in addition to the contractual relationships with thevendors. These orders must be processed and tracked as the ordersprogress through the approval process such that the individuals placingorders are notified of whether the order was approved or denied, as wellas for internal audit purposes. Therefore, there is a need for a systemand method that can provide an efficient and simple procurement processthat is easily customizable for multiple organizations and multiplevendors with simple and complex business terms, and can also provide asingle point-of-access for both businesses and consumers to interface,interact, and implement and execute transactions, in accordance withexisting or newly defined relationships, using a custom and configurablemethodology for realizing their requirements.

SUMMARY OF THE INVENTION

Accordingly, the present invention is directed to a procurement systemand method over a network using a single instance multi-tenantarchitecture that substantially obviates one or more problems due tolimitations and disadvantages of the related art.

An object of the present invention is to provide a system and methodthat can provide an efficient and simple procurement process that iseasily customizable for multiple organizations and multiple vendors withsimple and complex business terms, and can also provide a singlepoint-of-access for both businesses and consumers to interface,interact, and implement and execute transactions, in accordance withexisting or newly defined relationships, using a custom and configurablemethodology for realizing their requirements.

Additional features and advantages of the invention will be set forth inthe description which follows, and in part will be apparent from thedescription, or may be learned by practice of the invention. Theobjectives and other advantages of the invention will be realized andattained by the structure particularly pointed out in the writtendescription and claims hereof as well as the appended drawings.

To achieve these and other advantages and in accordance with the purposeof the present invention, as embodied and broadly described, a singleinstance, multi-tenant procurement system includes an access module toprovide access to a plurality of end users associated with anorganization to their respective accounts, each account being customizedby a super user of the organization, a search engine to execute searchesfor products offered by one or more suppliers, a transaction module toprocess and track one or more requisitions generated by the plurality ofend users, a business rules module to apply business rules establishedbetween the organization and the one or more suppliers to process therequisitions, and a data repository to store data generated on thesystem.

In another aspect, a method includes the steps of accessing a singleinstance, multi-tenant procurement system through an access module,customizing one or more end user accounts of an organization through theaccess module by a super user of the organization, executing searchesfor products offered by one or more suppliers through a search engine,processing one or more requisitions generated on the one or more enduser accounts by applying business rules established between theorganization and the one or more suppliers to process the requisitions,and storing generated data in a data repository.

In yet another aspect, a computer program product including a computerreadable medium having stored thereon computer executable instructionsthat, when executed on a computer, configures the computer to perform amethod including the steps of accessing a single instance, multi-tenantprocurement system through an access module, customizing one or more enduser accounts of an organization through the access module by a superuser of the organization, executing searches for products offered by oneor more suppliers through a search engine, processing one or morerequisitions generated on the one or more end user accounts by applyingbusiness rules established between the organization and the one or moresuppliers to process the requisitions, and storing generated data in adata repository.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory and areintended to provide further explanation of the invention as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide a furtherunderstanding of the invention and are incorporated in and constitute apart of the specification, illustrate embodiments of the invention andtogether with the description serve to explain the principles of theinvention. In the drawings:

FIG. 1 is a block diagram illustrating an exemplary embodiment of aneProcurement system in accordance with the present invention;

FIG. 2 illustrates an exemplary embodiment of an eProcurementarchitecture in accordance with the present invention;

FIG. 3 illustrates an exemplary user interface in accordance with thepresent invention.

FIGS. 4A-4T illustrate exemplary user management tools in accordancewith the present invention;

FIG. 5A illustrates an exemplary user setting tool in accordance withthe present invention;

FIG. 5B illustrates an exemplary roles selection tool in accordance withthe present invention;

FIG. 5C illustrates an exemplary email preference tool in accordancewith the present invention;

FIG. 5D illustrates an exemplary navigation setup tool in accordancewith the present invention;

FIG. 5E illustrates an exemplary user purchasing tool in accordance withthe present invention;

FIG. 5F illustrates an exemplary punch-out access tool in accordancewith the present invention;

FIGS. 5G-5M illustrate exemplary user permission tools in accordancewith the present invention;

FIGS. 5N-5O illustrate exemplary materials management tools inaccordance with the present invention;

FIGS. 6A-6J illustrate exemplary organization setup tools in accordancewith the present invention;

FIG. 7 illustrates an exemplary workflow setup tool in accordance withthe present invention;

FIGS. 8A-8D illustrate exemplary search engines in accordance with thepresent invention;

FIGS. 9A-9F illustrate exemplary catalog management tools in accordancewith the present invention;

FIG. 10 illustrates an exemplary contracts management tool in accordancewith the present invention;

FIGS. 11A-D illustrates an exemplary cart and requisition tool inaccordance with the present invention;

FIG. 12 illustrates an exemplary workflow setup tool in accordance withthe present invention;

FIG. 13 illustrates an exemplary purchase order approval tool inaccordance with the present invention; and

FIG. 14 illustrates an exemplary history tool in accordance with thepresent invention.

FIG. 15 illustrates the electronic procurement system communicating overa network with suppliers and purchasing organizations.

FIG. 16 illustrates the purchasing organization client communicatingover a network with the purchaser server application to access theengines of the purchaser server application.

FIG. 17 illustrates the supplier client communicating over a networkwith the supplier server application to access the engines of thesupplier server application.

FIG. 18 illustrates the features and database accessible via thesupplier client.

FIG. 19 illustrates the features and database accessible via thepurchasing organization client.

FIG. 20 illustrates a server system hosting an electronic procurementsystem running on the server.

FIG. 21 illustrates a client system providing access to an electronicprocurement system running on a server.

FIG. 22 illustrates a top-level data structure for electronicprocurement system.

FIG. 23 illustrates a data structure for a master database, showingcontents of a forms database.

FIG. 24 illustrates a data structure for a master database, showingcontents of a catalog database and search database for indexing themaster database.

FIG. 25 illustrates a data structure for a transaction database, showingcontents of a purchase order database.

FIG. 26 illustrates a data structure for a transaction database, showingcontents of a fax, distribution and revisions databases.

FIG. 27 illustrates a data structure for a transaction database, showingcontents of a requisition database.

FIG. 28 illustrates a data structure for a transaction database, showingcontents of a receipt database.

FIG. 29 illustrates a data structure for a transaction database, showingcontents of a sales order database.

FIG. 30 illustrates a data structure for a transaction database, showingcontents of a workflow database.

FIG. 31 illustrates a data structure for a staging database, showingcontents of a staging catalog database.

FIG. 32 illustrates a data structure for a transaction database, showingcontents of a contracts database.

FIG. 33 illustrates a data structure for a transaction database, showingcontents of a buyer invoice database.

FIG. 34 illustrates a data structure for a transaction database, showingcontents of a seller invoice database.

FIG. 35 illustrates a data structure for an end user database, showingcontents of a user/security database.

FIG. 36 illustrates a data structure for a scheduler database, showingcontents of the scheduler database.

FIG. 37 illustrates a prophetic block diagram of a server system,according to some embodiments.

FIG. 38 illustrates a prophetic block diagram of a server system,according to some embodiments.

FIG. 39 illustrates a prophetic block diagram of a process flowimplemented at a server system, according to some embodiments.

FIG. 40 illustrates a prophetic block diagram of an e-procurementprocess flow implemented at a server system, according to someembodiments.

FIG. 41 illustrates an exemplary data structure 4100 for an inventory ofan item, according to some embodiments.

FIG. 42 illustrates a prophetic block diagram of a process flow,implemented at a server system, according to some embodiments.

FIG. 43 illustrates an exemplary screenshot of a workflow configurationuser interface, according to some embodiments.

FIG. 44 illustrates an exemplary screenshot of an advanced dynamicworkflow setup rule group menu, according to some embodiments.

FIG. 45 illustrates an exemplary screenshot of a rules management setupmenu, according to some embodiments.

FIG. 46 illustrates an exemplary screenshot of an assign rule to groupmenu, according to some embodiments.

FIG. 47 illustrates an exemplary screenshot of an import/export rulesgroup menu, according to some embodiments.

FIG. 48 illustrates an exemplary screenshot of an item setup menu withina supplies manager application, according to some embodiments.

FIG. 49A illustrates an exemplary screenshot of a setup inventoryattributes menu, according to some embodiments.

FIG. 49B illustrates an exemplary screenshot of an item setup pricingmenu, according to some embodiments.

FIG. 49C illustrates an exemplary screenshot of an item setupreplenishment link menu, according to some embodiments.

FIG. 50 illustrates an exemplary screenshot of a supplier setupinventory parameters menu, according to some embodiments.

FIG. 51 illustrates an exemplary screenshot of a search results menu,according to some embodiments.

FIG. 52 illustrates an exemplary screenshot of a shopping cart menu,according to some embodiments.

FIG. 53 illustrates an exemplary screenshot of a sales order queue,according to some embodiments.

FIG. 54 illustrates an exemplary screenshot of a picking/packing slip,according to some embodiments.

FIG. 55 illustrates an exemplary screenshot of a purchase orderstatus/acknowledgement, according to some embodiments.

FIG. 56 illustrates an exemplary screenshot of a replenishment report,according to some embodiments.

FIG. 57 illustrates an exemplary screenshot of a replenishment order,according to some embodiments.

FIG. 58A illustrates an exemplary screenshot of a replenishment receipt,according to some embodiments.

FIG. 58B illustrates an exemplary screenshot of a replenishmentallocation, according to some embodiments.

FIG. 59A illustrates an exemplary screenshot of a setupfolders/automated robots screen, according to some embodiments.

FIG. 59B illustrates an exemplary screenshot of a setup workflow processscreen, according to some embodiments.

FIG. 59C illustrates an exemplary screenshot of an assign approversscreen, according to some embodiments.

FIG. 59D illustrates an exemplary screenshot of a review requiredapprovals screen, according to some embodiments.

FIG. 59E illustrates an exemplary screenshot of a review invoicesrequiring approval screen, according to some embodiments.

FIG. 60 illustrates a flowchart representing a server method for hostingan eProcurement system, according to some embodiments.

FIG. 61 illustrates a flowchart continuing the flowchart of FIG. 60,according to some embodiments.

FIG. 62 illustrates a flowchart representing a server method for hostingan eProcurement system, according to some embodiments.

FIG. 63 illustrates a flowchart representing a server method for hostingan eProcurement system, according to some embodiments.

FIG. 64 illustrates a flowchart representing a server method for hostingan eProcurement system, according to some embodiments.

FIG. 65 illustrates a flowchart representing a server method for hostingan eProcurement system, according to some embodiments.

FIG. 66 illustrates a flowchart representing a server method for hostingan eProcurement system, according to some embodiments.

FIG. 67 illustrates a flowchart representing a server method for hostingan eProcurement system, according to some embodiments.

FIG. 68 illustrates a flowchart representing a server method for hostingan eProcurement system, according to some embodiments.

FIG. 69 illustrates a prophetic block diagram of a server system,including an eProcurement provider hosted at the server system,according to some embodiments.

FIG. 70 illustrates a prophetic block diagram of an eProcurement systemhosted at a supplier server, according to some embodiments.

FIG. 71 illustrates a prophetic block diagram of an eProcurement systemhosted at a purchaser server, according to some embodiments.

FIG. 72 illustrates a flowchart representing a server method for hostingan eProcurement system, according to some embodiments.

FIG. 73 illustrates a flowchart representing a server method for hostingan eProcurement system, according to some embodiments.

FIG. 74 illustrates a flowchart representing a server method for hostingan eProcurement system, according to some embodiments.

FIG. 75 illustrates a listing of exemplary folders and robots, accordingto some embodiments.

FIGS. 76A-76B illustrate an exemplary field management interface inaccordance with the present invention.

FIGS. 77A-77C illustrate an exemplary update favorite(s) process flow inaccordance with the present invention.

FIGS. 78A-78B illustrate an exemplary document setup interface inaccordance with the present invention.

FIG. 79 illustrates an electronic procurement system hosted at asupplier server.

FIG. 80 illustrates an electronic procurement system hosted at apurchaser server.

DETAILED DESCRIPTION

Reference will now be made in detail to embodiments, examples of whichare illustrated in the accompanying drawings. In the following detaileddescription, numerous non-limiting specific details are set forth inorder to assist in understanding the subject matter presented herein. Itwill be apparent, however, to one of ordinary skill in the art thatvarious alternatives may be used without departing from the scope of thepresent invention and the subject matter may be practiced without thesespecific details. For example, it will be apparent to one of ordinaryskill in the art that the subject matter presented herein can beimplemented on any type of client-server compatible system containingany type of client, network, server, and database elements.

The terms module, engine, and application are used interchangeablyherein.

FIG. 1 is a block diagram illustrating an exemplary embodiment of aneProcurement system in accordance with the present invention. The term“eProcurement architecture” used herein refers to a system and methodthat facilitates customized searching, data modeling, and orderprocessing over an electronic network, using a client-server typearchitecture, where multi-tenants (e.g., end users/consumers, supplierusers, etc.) can realize each of their specific business requirementswith respect to the process of initiating and consummating transactions.In general, the eProcurement architecture of the present inventionfacilitates transactions between end users and suppliers. The end usersmay be individual users or members of an organization, such as a companyor institution. For example, the end users may be any member of theorganization authorized for performing procurement operations for theorganization or the end user may be an individual of a soleproprietorship.

In a multi-person organization, procurement operations of theorganization are setup in a multi-level structure with a group ofindividuals who make requests for requisitions and an authorizing entity(e.g., manager) who approve such requests based on the organization'sprocurement policies. There may be a plurality of individuals assignedas the authorizing entity, and the authorizing entity may itself includemultiple levels of authority with each higher level having more controlover the procurement operations. The procurement policies may define thelevels of authority, such as who can order what, and include one or morecontractual relationships between the organization and one or moresuppliers. By way of example only, the procurement policy may definethat the lowest level end user of a particular department can only ordercertain products or services while a higher level end user can order orauthorize orders of broader categories of products and/or services. Inanother example, the procurement policy may require that certainproducts or services be ordered exclusively from a supplier with anexclusive contract with the organization. As another example, theprocurement policy may require that a particular product be ordered in apredetermined lot size due to a contractual discount negotiated from aparticular supplier. The eProcurement architecture of the presentinvention facilitates transactions between multiple end users of anylevel of any organization with multiple suppliers taking into accountthe procurement policies associated with each end user and supplier on asingle platform (i.e., single instance, multi-tenant architecture).

As shown in FIG. 1, the eProcurement system 10 of the present inventionincludes end users 12, supplier users 14, and the procurement module 20connected over a data communications network 16. The procurement module20 includes access module 21, search engine 22, transaction module 23,business rules engine 24, and data repository 30. The data repository 30may include one or more databases to store user data 32, hosted productindex 34, product data 36, and transaction data 38.

The access module 21 allows the end users and suppliers to set up andgain access to their respective accounts in the eProcurement system 10.For example, the access module 21 may include registration/account setupprocedures to create a new account on the eProcurement system 10. Theaccess module 21 may also include authentication procedures (e.g., loginID and password) to determine the identity of the user and the user'sprofile (e.g., associated organization, level of access, etc.) beforegranting access to the procurement module 20. Once granted access, theuser may configure the account for customized access. If the user is a“super user” (i.e., a user with higher levels of access, such as aprocurement supervisor of an organization), the super user may setconditions for access of other users from his organization. If the useris a supplier, the supplier user may create or update the supplieraccount or provide/update product/service information (e.g., productcatalog).

The search engine 22 allows the user to search through the hostedproduct index 34 to find a product and/or service provided by the one ormore suppliers. In general, the search engine 22 searches through thehosted product index 34, which contains tokenized data of all theproducts from all the suppliers stored in the product database 36. Thesearch results of the search are processed by the business rules engine24 and displayed to the user based on the business rules set for theuser and the user's organization. The search engine 22 includes apunch-out module 22 a that allows the user to “punch-out” to an unhostedsupplier catalog for products/services not available through theeProcurement system 10. The user can only access those punch-outsuppliers configured for him/her according to the business rules engine24.

The transaction module 23 includes one or more of requisition module 23a, order module 23 b, and tracking module 23 c to facilitate atransaction with one or more suppliers. The requisition module 23 aprocesses items selected by the user from the search engine 22 andcreates a requisition. If authorization is required, the requisitionmodule 23 a notifies the designated authorizing entity of therequisition to obtain authorization. If the requisition is denied, therequisition module 23 a sends a notification back to the user of thedecision. If the requisition is approved, the user is notified and therequisition either a) is sent to order module 23 b, or b) is marked as“complete” based on the business rules engine 24 because not allrequisitions are necessarily converted to orders. The order module 23 bconverts the requisition into a purchase order according to the businessrules in the business rules engine 24. The order module 23 b sends thepurchase order to the appropriate supplier in the proper format(s)designated for that supplier. Once the purchase order has been sent, thetracking module 23 receives confirmation of the purchase orders from thesuppliers and keeps track of the purchase orders through the fulfillmentprocess.

In general, a user (i.e., end user, super user, supplier user, etc.)gains access to the procurement module 20 through the access module 21.The access module 21 may include security measures, such asauthentication (e.g., providing user ID and password), to identify theuser by accessing the user data stored in the user database 32. Useraccounts may also be created through the access module 21. For example,a user (generally a super user) creates an account on the eProcurementsystem 10 by registering through the access module 21. The account mayalso be created by a system administrator of the eProcurement system 10off-line who gives access to the user via emailing a registration linkto the access module 21. Once an account has been created, the user mayaccess the eProcurement system 10 through the access module 21.

FIG. 2 illustrates an exemplary embodiment of an eProcurementarchitecture in accordance with the present invention. As shown in FIG.2, the eProcurement architecture of the present invention may includeone or more end user/consumer interfaces 212 and supplier userinterfaces 214, which may connect to one or more servers 220 over awired or wireless network 216. These one or more servers 220 may be foruser processing (e.g., end user processing servers 221), productdatabase hosting (e.g., custom database servers 222), transactionprocessing (e.g., transaction processing servers 223), middleware/webmethods (e.g., middleware/web methods servers (e.g., business rules)224—e.g., for implementing business rules between end users and supplierusers), and communication processing (e.g., web servers 225), such asstreaming data/media, file hosting (e.g., FTP—File TransferProtocol—server), web serving (e.g., HTTP/HTTPS, WWW, CGI—Common GatewayInterface, ASP—Active Server Pages, Servlets, JSP—Java Server Pages,etc.), facsimile transmission, proxy, telnet, chat, list, mail (e.g.,SMTP—Simple Mail Transfer Protocol), news (e.g., NNTP—Network NewsTransfer Protocol), groupware, and other communication/data processingpurposes. These one or more servers 220 may be hosted behind or outsidea firewall 218 with or without failover and/or load balancers. These oneor more servers 220 may be hosted over the Internet, within the sameIntranet and/or subnet, on different Intranets and/or subnets, or in anyother inter-networked configuration of network 216. The servers 220 maybe implemented on Microsoft™ Windows NT/2000/XP™/XPProfessional/Server™/Vista™ (e.g., Microsoft™ Internet InformationServices (IIS)), Apache, Unix™, z/OS™, z/VM™, Linux™, VMS, NetscapeEnterprise Server™, iPlanet™ Web Server, Sun Java System Web Server,Oracle™ Server, SQL Server™ (e.g., Microsoft™, Sybase™, MySQL™ etc.),Terradata server applications, or any other compatible servertechnology.

End user interfaces 212 and supplier user interfaces 214 may beimplemented on Internet web browsers such as Microsoft InternetExplorer™, Netscape Navigator™, Mozilla™ Firefox™, Opera, Satori,Blazer, or any other Internet web browser capable of sending andreceiving data using the Hypertext Transfer Protocol (HTTP). The datamay be transferred over an encrypted and authenticated communicationlayer (i.e., using secure HTTP, or as more commonly known, HTTPS). Enduser interfaces 212 and supplier user interfaces 214 may be implementedusing a combination of HTML (Hypertext Markup Language), MacromediaFlash™, XML (Extensible Markup Language), CGI (Client GatewayInterface), ASP (Active Server Pages), JSP™ (JavaServer Pages), PHP(Hypertext Preprocessor), Java, C/C++, Visual Basic™, Visual BasicScript, Perl™, Tcl/Tk, SQL (Structured Query Language), and any otherrelevant markup/programming/scripting/query language or developmentenvironment.

Communication from the end user interfaces 212 and supplier userinterfaces 214 to the server or plurality of servers 220, via thefirewall 218 with failover and load balancer, may be implemented overwired communication protocols through network 216. For example, at theWide Area Network (WAN) level or at the Local Area Network (LAN) level,routed Internet Protocol (IP) packets may be transported using the IEEE802.3 Ethernet standard, for example, on the data link network layer.However, any network standard may be used, whether for packetencapsulation, path determination and logical addressing, or physicaladdressing, at any layer of these layers without departing from thescope of the invention. Also, the packet data may be transported overinterconnected hubs (not shown), switches 226, routers 227, and othernetwork elements. At the WAN level, protocols such as Packet overSynchronous Optical Network (SONET) or Synchronous Digital Hierarchy(SDH), Asynchronous Transfer Mode (ATM) over SONET, Multi-protocol LabelSwitching (MPLS), packet over Frame Relay, or other analogous protocolsmay be used to deliver data over longer distances. Interconnectrepeaters, multiplexers (e.g., add/drop), and cross connects may be usedto facilitate and ensure accurate transmission over the long-haul frompoint-to-point.

Communication from the end user interface 212 and supplier userinterfaces 214 to the server or plurality of servers 220, via thefirewall 218 with failover and load balancer, may also be implementedover wireless communication protocols over network 216. For example, atthe LAN level (i.e., WiFi), standards such as 802.11a, 802.11b, 802.11g,and 802.11n may be used to deliver data from point-to-point. Similarly,at the Metropolitan Area Network (MAN)/WAN level, standards such as802.16e (i.e., WirelessMAN), WiMax, Universal Mobile TelecommunicationsSystem (UMTS) over Wideband Code Division Multiple Access (W-CDMA), GSM,GPRS, or EDGE may also be used to deliver data from point-to-point. Aswith the wired networks, other standards and protocols may be usedwithout departing from the scope of the invention.

The eProcurement architecture of the present invention includes a datarepository 230. The data repository 230 may be implemented using one ormore databases to store end user data 232, hosted product index 234,master product data 236, and transaction data 238, in accordance withbusiness rules (implemented via, for example, a business rules engine24). The data repository 230 may be implemented using any type of datastorage device without departing from the scope of the presentinvention. Moreover, the data repository 230 may be managed by anydatabase platform (e.g., Oracle, Microsoft Access, IBM DB2, etc.)without departing from the scope of the present invention.

End user interfaces 212 and supplier user interfaces 214 may also allowan implemented feature that enables the setting of user configurationpreferences. This feature allows a super user, with enhancedadministrative capabilities, to have full access to the features of enduser and supplier user interfaces. Some of these features may include:sending an email notification of a specific requisition order, and acorresponding link for accessing the same; full access to the featuresof the end user and supplier user interfaces; the capability to approveor reject a full order or a specific order item requested by an enduser; the capability to take ownership and/or control of a specificrequisition order, which may be organized according to a product orsupplier category; the capability to expedite or accelerate an orderthrough to specific steps along the ordering process, including thefinal review step; and, the capability to invoke and view a summary andhistory of each end user's latest order activity.

Moreover, a super user, for example, may design and/or otherwiseconfigure and customize the style, type, layout, and level of data thatis displayed on the respective end user interface 212 and supplierinterface 214 for their respective organizations. A super user is alsoable to invoke a setup feature to choose which end users may have accessto specific suppliers. Furthermore, a super user may also determine whatinformation is required from the end users and supplier users of theirrespective organization, and determine the level of access at which anend user may access a specific supplier within the hosted supplierproducts catalog. This capability enables a super user to configure, forexample, whether an end user can view specific products from specificsuppliers, the currencies given for product/item pricing, and placeorders. Moreover, the end user interface of the present invention allowsfor features of the present invention to be configured as permissiondriven. As such, certain features may be accessible to each end user,based on the end user's precedence within the organization, which likelyaffects his/her corresponding permission level. In addition, eachfeature is configurable to each end user based on a set of variableoptions. These variable options may include the ability to set aspecific layout/view, a preferred number of search results, a preferredlist of products, or a preferred list of suppliers. Also, each featuremay include a help function that allows an end user to resolve inquiriesor difficulties relating to the feature. The end user interfaceimplementation is usually account login-based and, as described infurther detail above, may encompass multiple server types (e.g., runninga Linux OS), a redundant firewall and load balancer, and apriority-based software programming architecture (e.g., implemented inJAVA and JSP).

FIG. 3 illustrates an exemplary user interface in accordance with thepresent invention. For purposes of example only, an end user interfaceis used to describe various aspects of the present invention. As shownin FIG. 3, user interface 300 provides customized information for theuser. For example, the user is a member of a fictitious group named WeetOrganization. The user interface 300 includes one or more of anorganizational message area 310, any system message area 320, and taskitems area 330. In the example shown, the user is a super user andtherefore, the “Admin” tab 340 is active. Had the user been an end user,the “User” tab would be active and the “Admin” tab 340 either would notbe displayed or would be inactive. All of these areas and informationdisplayed therein may be customized through the access module 21. Anyconfiguration definitions are then stored in the user database 32 andinvoked upon access/login.

FIG. 3 illustrates an exemplary embodiment of the configuration toolsavailable to a super user. In general, the eProcurement system 10 of thepresent invention provides a super user the tools needed to configureevery aspect of the eProcurement process of an organization for completecustomization, thereby effectuating a single instance multi-tenantarchitecture. That is, the eProcurement system 10 establishes acentralized system that is customizable for each user and/ororganization, thereby providing a robust and yet an efficienteProcurement system. More specifically, configuration tool 350 allows asuper user to customize the configuration of the eProcurement system 10specifically for an organization and its users. While exemplaryconfiguration tools are shown, other tools may be included withoutdeparting from the scope of the present invention.

FIG. 4A illustrates an exemplary user management tool 400 to create ormodify user access, manage user registration, and define theorganizational structure. For example, FIG. 4A illustrates a user accesshuman resources (HR) configuration tool 440. In particular, HRconfiguration tool 440 allows the super user to establish and describethe organization. For example, the HR configuration tool 440 may be usedto define various departments of the organization (442), variouspositions of the organization (444), various roles of the users in theorganization (446), and relationships between the roles, positions, anddepartments defined for the organization (448). As shown in FIG. 4A, thevarious departments of the organization that require procurementservices may be “Engineering,” “IT,” “Legal,” “Math,” etc. As shown inFIG. 4B, there may be various positions within the organization, such as“Buyer,” “Documentation Editor,” “Professor, “Researcher,” etc. As shownin FIG. 4C, the HR configuration tool 440 is used to define variousroles of the users within the organization, such as “Administrator,”“Approver,” “Catalog Manager,” etc. As shown in FIG. 4D, the HRconfiguration tool 440 is used to define the relationship between thedepartment, position, and role of the users. For example, a “Professor”in “Engineering” may be designated as an “Approver” and “Requisitioner”for the organization while a “Researcher” of “Engineering” may only be a“Requisitioner.” In this manner, the HR configuration tool 440 providesa simple yet efficient mechanism to define the organization for whichthe eProcurement system 10 is to be utilized.

Once the organization has been defined through the HR configuration tool440, user access tool 410 may be used to create or modify a user'saccess to the eProcurement system 10 for the user's organization. Asshown in FIG. 4E, the user access tool 410 may be used to create a newuser access account (410 a) or the user database 32 may be searched (410b) for an existing user in the eProcurement system 10. To create a useraccess account, the user access tool 410 requires entry of the user'spersonal information (e.g., name, phone number(s), email address) andauthentication information (e.g., login ID and password). In addition,the user's department and position information as created through the HRconfiguration tool 440 is also provided. In an exemplary embodiment, thedepartment and position information created through the HR configurationtool 440 are shown in a drop-down menu for easy selection and entry. Tosimplify the creation of an account, existing user files may be importedinto the user database through the user import 430. Once a user accessaccount has been created, the newly created accounts are activatedthrough the user registration monitor 420. As shown in FIG. 4F, a listof new user access requests is presented in the user registrationmonitor 420. A designated approver for the organization then reviews andapproves the user access account to be activated for the user.

In accordance with an exemplary embodiment of the present invention,every aspect of the organization may be defined and customized in theeProcurement system 10. For example, as shown in FIG. 4A, once a“Department” has been created for an organization, the createddepartment may be activated (442 a). Moreover, each department may bedefined with business rules related to the department's requisition (442b), purchase orders (442 c), and fulfillment (442 d). For example, FIG.4A shows that the “Engineering” department has been designated as anactive department with the “Requisition” and “Purchase Order” rulesincluding a list of approvers for the Engineering department. As shownin FIG. 4B, a created position may be designated for a createddepartment. For example, FIG. 4B shows that the organization has the“Professor” position for the “Engineering,” “Math,” “Microbiology,” and“Purchasing” departments. FIG. 4G illustrates an exemplary embodiment ofthe HR configuration tool 440 for defining roles of the organization.

For each role, the roles configuration tool 446 is used to define therole properties (446 a), purchasing properties (446 b), accesspermissions (446 c), materials management rules (446 d), and history ofmodifications to these definitions (446 e). For example, for the role of“Administrator,” the role properties 446 a (FIG. 4G) may include whetherthe designated role is active in the organization and the purchasingproperties 446 b may include definitions of any internal and externalpurchasing codes and information (e.g., “PRWF”) (FIG. 4H),purchasing/approval limits (FIG. 4I), allowed product views (FIG. 4J),and allowed punch-out access (FIG. 4K). The access permissions 446 c maybe defined for the roles including shopping cart permissions (FIG. 4L),orders (FIG. 4M), approvals (FIG. 4N), accounts payable (FIG. 4O),administration (FIG. 4P), management of materials (FIG. 4Q), and customfields permissions (FIG. 4R). The materials management 446 d defines theavailable projects and location of groups to the various roles (FIG.4S). The history section 446 e keeps track of a history of all theactions (e.g., modified, created, product view added, product viewremoved, punch-out access added, punch-out access removed, projectadded, project removed, location added, location removed, etc.) and thesections to which the actions were applied (e.g., role properties,product views, punch-out access, materials management, permissions,purchasing/approval limits, custom field permission definitions, etc.)including the old value of the parameter and the new value of theparameter (FIG. 4T).

Once the internal organizational structure and descriptions of keypositions of users in the organization have been defined using the usermanagement tool 400, specific users and their level of access may bedefined. As discussed above, the level of access of a user may beassigned globally based on their positions and/or roles in theorganization. In addition, the eProcurement architecture of the presentinvention allows customization down to specific individuals all withinthe single instance, multi-tenant environment. For example, FIG. 5Aillustrates an exemplary user profile tool 500 for defining a user'saccount in the eProcurement system of the present invention. As shown,the user profile tool 500 includes one or more of a user setting tool510 (comprising a user identification tool 510 a for entering useridentification data), user purchasing tool 520, user permissions tool530, user materials management tool 540, and user setting history tool550. These tools provide customization of the user's account for variouslevels of access to the eProcurement system of the present invention allwithin the single instance, multi-tenant environment.

For example, as shown in FIG. 5A, an exemplary user setting tool 510 ofthe present invention shows that the user is a “Professor” in the“Engineering” department. As discussed above, users in this departmentand position have default levels of access defined by a super user usingthe user management tool 400. However, because a user may haveadditional roles assigned to the user that are beyond the normal scopeof the user's position, the eProcurement system of the present inventionallows a super user to modify the user's level of access on anindividual level. For example, FIG. 5B illustrates an exemplary rolesselection tool 510 c to modify the roles assigned to the selected user.Through the roles selection tool 510 c, a super user may be able tospecifically tailor the roles of a user down to the individual level toprovide customized access to the eProcurement system of the presentinvention. Similarly, the user's departmental permissions may bemodified using the department permissions tool 510 d. Various aspects ofthe user's account may also be customized, such as the user's personalsettings 510 b, email preferences 510 e, and navigation setup 510 f. Aswith the user management tool 400 and the roles/permissions tools 510 cand 510 d, all customizations may be performed by simplyactivating/deactivating a function available on the eProcurement systemof the present invention. For example, FIG. 5C illustrates an exemplaryemail preference tool 510 e, which lists all of the action notificationsthat may be received via email. A user only has to activate/deactivate apreference by selecting the notifications the user wishes to receive viaemail. Similarly, FIG. 5D illustrates an exemplary navigation setup tool510 f. As shown, a user simply selects the navigation tools to bedisplayed (or removed) from the top-level navigation bar.

The user purchasing tool 520 shown in FIG. 5E allows a super user todefine the purchasing activities of the user. For example, as shown inFIG. 5E, user purchasing tool 520 includes one or more of the customfields tool 520 a, financial approvers tool 520 b, purchasing/approvallimits tool 520 c, shipping/billing address tool 520 d, product viewstool 520 e, and punch-out access tool 520 f. The custom fields tool 520a is similar to the purchasing properties tool 446 b (FIG. 4H) to definethe internal and external codes needed to make a purchase (e.g., productcode). The financial approvers tool 520 b designates purchase approversfor the user. Default, preferred, and additional approvers may bedesignated through the financial approvers tool 520 b as well asremoving approvers for the user. The purchasing/approval limits tool 520c designates the limits of purchases and/or approvals of purchasesallowed for the user. FIG. 5E illustrates an exemplary view of thepurchasing/approval limits tool 520 c. As shown, the limit values ofvarious activities related to purchases may be defined for the user. Theshipping/billing address tool 520 d designates the shipping/billingaddress associated with the user. The product views tool 520 edesignates the type of products the user is allowed to view. Thepunch-out access tool 520 f designates the punch-out catalogs that areallowed to be accessed by the user. For example, FIG. 5F illustrates anexemplary punch-out access tool 520 f. As discussed above, thesesettings may be designated as a default based on thedepartment/position/role assigned to the user. However, these tools maybe used to customize the default settings for the specific individualuser in accordance with the present invention.

In a similar fashion, the user permissions tool 530 includes one or moreof tools to customize the user's access to the shopping cart (FIG. 5G),order processing (FIG. 5H), approval processing (FIG. 51), accountspayable processing (FIG. 5J), administration permissions (FIG. 5K),materials management (FIG. 5L), and custom fields permissions (FIG. 5M).The materials management tool 540 designates inventory locations basedon projects and groups (FIG. 5N) as well as default/preferred accesslocations (FIG. 50). As discussed above, the history tool 550 keepstrack of all actions/changes made to the various parameters.

FIG. 6A illustrates an exemplary organization setup tool 600 fordesignating business rules such as method of payment (FIG. 6A), tax(FIG. 6B), shipping/handling (FIG. 6C), settlement (FIG. 6D), purchaseorder terms (FIGS. 6E-G), order distribution process (FIGS. 6I-J), andhistory of all actions effectuated through the organization setup tool.By organizing all of the terms and conditions of an order for eachorganization in a single instance, multi-tenant architecture, eachrequisition effectuated on the eProcurement system of the presentinvention is processed efficiently.

FIG. 7 illustrates an exemplary workflow setup tool 700 to define theworkflow process of a requisition, purchase order, and fulfillment. Asshown in FIG. 7, the workflow setup tool 700 in accordance with thepresent invention creates a shared workflow space 710 and allows for theassignment of users (e.g., individual users, or users of various userroles) to be included in the workflow process.

Other configuration tools include document setup tool (FIG. 102,document setup interface) to organize documents related to requisitions,purchase orders, and sales orders for access by the user. The documentsetup tool keeps track of the name of the document creator, versionnumber, and any deployment dates, as well as other data related to thedocument. Moreover, the eProcurement system in accordance with thepresent invention includes a field management tool (FIG. 100, exemplaryfield management interface) that allows super users to create, modify,and manage every field/parameter related to the procurement process usedon the system. Accordingly, the eProcurement system of the presentinvention may be custom tailored for each organization/user role/userwhile maintaining its single instance, multi-tenant environment.

As shown in FIG. 2, end user interfaces 212 and supplier user interfaces214 according to the present invention provide access to the pluralityof modules of the eProcurement system 10 (FIG. 1). As described above,the end user interface 212 is configurable by both end user and superusers. Moreover, the end user interface 212 includes one or morefeatures, for example, such as searching and viewing a hosted supplierproducts catalog, invoking purchase/requisition orders, consummatingsales transactions, invoking status queries and viewing the response,and setting end user configuration preferences as described furtherbelow. For example, the search and view feature allows for searching viaproduct description, supplier name, manufacturer name, catalog no.(SKU), a filtering capability, and by browsing: catalog/non-catalogitems, suppliers, or contracts. A user may invoke any of these searchinputs alone or in combination with others. Also, Boolean and fuzzylogic functionality is available for searching and allows a user todevise targeted search strategies that may return more accurate searchresults. Once a user has invoked a search using any of the inputsdescribed, the user may then view the returned results. The returnedresults can be filtered by a user based on category or supplier. Also, auser may choose to organize the returned results such that similarresults are listed in proximity of one another. For example, a user mayorganize returned results by weight, supplier, category, catalog number,product description, UOM, product size, price, quantity, and/orcurrency.

The catalog may be implemented as single instance but multi-tenant (or,as multiple instance, single-tenant), and may further include customviews of items as set by each internal end user and/or organization. Anend user may specify favorites within the catalog. Such favorites areavailable for later viewing or purchasing by the end user. Any updatesmade to an end user favorite within the catalog will be automaticallypropagated to the end user's favorite(s) view as well (FIG. 101, anexemplary update favorite(s) process flow). The catalog may allow forsupplier classifications and multiple products may be linked to a singlesupplier. Also, the catalog can be activated or deactivated through asimple click on the end user interface, and specific product categoriescan be globally manipulated and applied to affect all end users. Eachcatalog may contain information regarding one or more suppliers, and amaster product database is primarily tasked with populating each hostedsupplier products catalog. This master product database is a relativelylarge database with a plurality of attributes related to one or morespecific products.

In addition to the hosted supplier products catalog, punch-out catalogsmay also be implemented as an alternative and supplement to the hostedsupplier products catalog, and are made available, for example, when thehosted supplier products catalog does not yield sufficient orsatisfactory results. The punch-out catalogs link to outside/third-partycatalogs, are not hosted, and may also contain end userorganization-specific prices. Processing modules executed on the customdatabase servers invoke each punch-out instance. Multiple punch-outcatalogs may be accessible by a single end user. An end user can returnfrom a punch-out catalog to the hosted supplier products catalog, andthe remainder of the features of the eProcurement architecture, via asubmit feature, which will then return to the processing module thatinitially invoked the punch-out instance. Punch-out catalogs may beconfigured to display relevant catalogs to an end user, based on the enduser organization. An end user can browse punch-out catalogs to searchfor more accurate results and may, subsequently, invoke a requisitionorder via the third-party web site and order processing methods. Also,one or more purchase orders can be sent from one or more punch-outcatalogs, but each punch-out order session may generate a singlepurchase order that may ultimately include orders from non-punch-out orhosted catalogs.

Further, with respect to the hosted supplier products catalog, there maybe a feature implemented to allow both its searching and viewing. Thesearch/view catalog feature is invoked via a processing module thatexecutes on the custom database servers. Upon the execution of such asearch by an end user, search results can be displayed via the end userinterface. The catalog search results can be displayed, for example,using a static or dynamic interactive list or table, attachment,graphic, or link. An end user may also have the option of choosing theappropriate supplier(s) from which to place an order. Upon an end user'sselection of a particular supplier, the relevant supplier data is thenforwarded to the transaction processing feature. The end user may laterinvoke a status query, via a processing module executed on the customdatabase servers, on a preexisting order and, subsequently, receivestatus notifications regarding the order.

The search feature may be implemented using several sub-features suchas, for example, customized annotations (with icons) ofpreferred/contract suppliers, a product/supplier filter, and a productsize filter. The search feature is invoked by a processing module thatis executed on the custom database servers. The customized annotations(with icons) of preferred/contract suppliers allows certain products tobe highlighted within search results. Furthermore, the product/supplierfilter of the search feature allows certain products to be displayed,while others are hidden, depending on specific filter criteria chosen bythe end user/organization. Such criteria may include, for example, pricethresholds, hazard level, approximate delivery date, product size,supplier, and/or currency.

The search architecture is based upon an indexed, tokenized-typeimplementation. This search architecture may include a search engine anda tokenization feature, both of which are invoked via processing modulesexecuted on the custom database servers. Product elements such as theproduct name, industry, price, currency, and availability, among others,are primarily used to generate a product search index (e.g., a token).The process of generating a product search index/token is called“tokenization” and may be executed by a tokenization feature invoked viaa processing module. The indices/tokens generated as a result of thetokenization feature, which relate to various products of a multitude ofsuppliers, may be stored within and executed on the hosted supplierproducts catalog. Searching is executed against “verticals.” A verticalis designed similar to a drill-down menu architecture that consists ofroot nodes and leaf nodes, which are children of their respective roots.Through the use of tokenization and verticals, a layer of abstraction isadded that is unique in comparison to typical text-based searching of alarge database, like the master product database. This added layer ofabstraction allows for better organization of the underlying data. As aconsequence, the use of tokens to search verticals, which organizesupplier product data and search the hosted supplier products catalog,enables an efficient and methodical search strategy to be executed.Search results returned from searching the hosted supplier productscatalog are forwarded back to the search engine and may appear via theend user or supplier user interfaces. For an end user, designatedpreferred suppliers usually appear first in the search results.

Further contained within the search architecture, a feature to allow theinvocation of status queries and viewing of the response may beimplemented. This feature allows a plurality of end users to sendqueries/requests via middleware/web methods, or direct Internet postingtechniques, to the product catalog. The feature is itself invoked by aprocessing module that executes on the custom database servers. Suchqueries/requests may be intended for finding, buying, or managingproducts. Such products may be those of preferred contractors that arematched to the end user based on a plurality of criteria likepermission, product type, industry, price, quality control metrics,delivery date, warranty types, currency, and/or locale. Each productcatalog may contain information regarding one or more specific products.A master product database populates the hosted supplier products catalogwith various types of information relating to one or more specificproducts. The various types of information may include a “stock keepingunit” (SKU) identifier, supplier information, and productcategory/description/attribute information.

Further also to the search architecture, an in-stock query feature maybe implemented to allow an end user, through the middleware/web methods,or direct Internet posting techniques, to determine whether any suppliermight have a particular product in-stock, and/or the warehouse/locationwhere that stock is maintained. The feature is itself invoked by aprocessing module that executes on the custom database servers. Once thein-stock query feature is invoked, relevant suppliers are sentindividual queries. Subsequently, each supplier response to an in-stockquery is processed and the appropriate end user is notified after thein-stock query receives the supplier response(s), but before returningto the processing module.

Moreover, a quick order feature may also be implemented to enableseveral other sub-features such as, for example, searching by productcategory, SKU identifier, currency, or host product categorynumber/supplier part number. The feature is itself invoked by aprocessing module that executes on the custom database servers.Subsequently, the order feature is initially invoked by an end user thathas completed a quick order search. Thus, the quick order featureenables an end user that may have knowledge of specific productattributes to perform an expedited search, retrieve search results, andproceed to ordering.

The search results of a product search exhibit other features of theinvention such as those related to the presentation of results. Forexample, suppliers and categories contained within search results can bedisplayed using different customizable icons, which may be used tohighlight specific suppliers and product categories. Such results canalso be ranked according to priority based on whether they are suppliedfrom preferred or contracted suppliers, a preferred category of productsfrom suppliers, or a preferred currency. Non-preferred or non-contractedsupplier or currency results may also presented to end users. Moreover,a product comparison chart can be invoked to highlight the differencesand similarities among two or more products. The chart can containstatic or dynamic presentation attributes based in part onsupplier-provided data. For example, the in-stock attribute, a dynamicpresentation attribute, can be used to identify whether specificproducts are actually available in a supplier's inventory, and theircorresponding prices and/or currencies. A search result list can beorganized by category and/or vendor based on end user preferences. Also,icons can be used to further display and highlight relevant informationregarding products such as, for example, whether products are hazardous,toxic, poisonous, or are considered to be controlled substances. Aproprietary taxonomy can also be implemented against modeling productcategories to enable more efficient searching and, ultimately,user-friendly, organized search results.

FIGS. 8A-8D illustrate exemplary search engines in accordance with thepresent invention. For example, FIG. 8A illustrates an exemplaryparametric search engine 810 and punch-out catalogs 820. FIG. 8Billustrates an exemplary quick order search engine 830. FIG. 8Cillustrates an exemplary browsing engine based on suppliers. FIG. 8Dillustrates an exemplary browsing engine based on categories of theproducts and/or services. Other search engines may be used withoutdeparting from the scope of the present invention. Therefore, aneProcurement system in accordance with the present invention couples theconfiguration tools described above for customizing access to specifiedsuppliers and/or specified types of products based on department,position, roles, and/or permissions of the user for each organizationwith various search engines in a single instance, multi-tenantarchitecture.

As shown in FIG. 2, the supplier user interface 214 in accordance withthe present invention and further described below is configurable bysupplier users and super users, and includes one or more features, forexample, such as accessing a supplier hosted products catalog, viewingand responding to purchase orders, consummating sales transactions,viewing and responding to status queries, and setting supplier userconfiguration preferences. Each individual end user and supplier usermay have a different interface from another end user and supplier user,respectively. Furthermore, the supplier end user interface of thepresent invention may allow a plurality of supplier users to sendqueries/requests via middleware/web methods server 224 to customdatabase servers 222, and to a hosted supplier products catalog 234 thatis multi-tenant managed. A remote supplier user query/request is sentvia the supplier end user interface 214 over the Internet, or othernetworked connection, and is first received by the web servers 225 afterpassing through the firewall 218. Then, the web server 225 passes thequery/request to the middleware/web methods server 224, where businessrules may be enforced. Subsequently, depending on whether thequery/request is related to a transaction or a user search, it is eitherforwarded to the transaction processing servers 223 or custom databaseservers 222, respectively. For either type of query/request, the hostedsupplier products catalog 234 is then readily accessible via processingmodules for exchanging transaction/product data, or performing asearch/supplier operation. The hosted supplier products catalog 234 canserve as a quasi-link between the end user interface and the supplierinterface because it is accessible by both interfaces. Supplier userscan access the catalog via the middleware/web methods servers 224, whichthen forward the supplier access request to the custom database servers222 and processing modules for execution, in order, for example, toupdate their own supplier data. End users may be able to search multiplesuppliers within the catalog via the end user interface 212, subject toaccess rules set by a super user. End users may search the catalog forspecific end user product requirements via the middleware/web methodsservers 224, which forward the end user search request to customdatabase servers 222 and processing modules for execution. Subsequently,the end user may then invoke requisition and purchase orders via themiddleware/web methods servers 224, which forward the end user order tothe transaction processing servers 223 for execution.

As described above, to support the product search function, theeProcurement system of the present invention includes a master catalogdatabase of all the products from all the suppliers hosted on the systemto implement a single instance, multi-tenant environment. Accordingly,the eProcurement system of the present invention includes a catalogmanagement tool 900. The catalog management tool 900 includes one ormore of supplier tool 910, categories tool 920, supplier classificationtool 930, category classification tool 940, product views tool 950,pricing tool 960, map attributes tool 970, and consortium managementtool 980.

FIG. 9A illustrates an exemplary catalog management tool 900 with anexemplary supplier tool 910 invoked. The supplier tool 910 includes asearch engine that searches for existing suppliers hosted in theeProcurement system of the present invention. Furthermore, the suppliertool 910 adds new suppliers not yet hosted in the system. FIG. 9Billustrates an exemplary categories tool 920 that configures all theproducts offered from the hosted suppliers into defined categories.Classifications for suppliers and product categories within the systemof the present invention are defined and managed by the supplierclassification tool 930 (FIG. 9C) and category classification tool 940(FIG. 9D). In particular, new classes of suppliers and productcategories may be created, defined, and configured as needed through thesupplier classification tool 930 and category classification tool 940.In addition, existing classifications of suppliers and productcategories may be modified. The product views tool 950 manages the viewsof products based on the defined supplier and product categories (FIG.9E).

FIG. 9F illustrates an exemplary pricing tool in accordance with thepresent invention. As shown, pricing tool 960 manages various pricingsets of each hosted supplier for the hosted products (or, the tool 960may also be applied to non-catalog items, forms, or other non-hostedsuppliers or products/items). The pricing set types may includeorganizational prices, contract prices, list prices, and consortiumprices. Other pricing sets may be used without departing from the scopeof the invention. The pricing tool 960 tracks versions of each type ofpricing sets, status of the pricing sets (e.g., implicitly approved, notreviewed, rejected, approved, etc.), as well as the audit history ofeach pricing set. Accordingly, the appropriate pricing set may betracked, managed, and invoked for each organization for each type ofproduct.

Other types of catalog management tool 900 include the map attributetool 970 and consortium tool 980. The map attribute tool 970 managesvarious parameters of the procurement activity, such as product codes,parameter format, and unit of measure (UOM). For example, commodity codeconfiguration parameters may be set through the map attribute tool 970to determine if and how the category taxonomy is to be mapped to, forexample, an organization's set of category/commodity values. Thecommodity codes may be modified as categories, sub-categories, and ondown to the product level. The list of values may be set manually orimported/exported from/to an already existing file. As another example,universal product codes (e.g., UN/SPSC) and UOM may also be configuredto be mapped to an internal organization codes for automatic conversionwhen searching, viewing, and ordering products. Further, UOM may bemapped from standard UOM to organization specific UOM. The consortiumtool 980 defines various consortiums that an organization may be amember of and offer consortium pricing by designating a supplier as aconsortium supplier. Hence, all organizations that are members of theconsortium will be offered the consortium pricing set when ordering fromthe designated supplier.

As shown in FIG. 2, the server technology of the present inventionincludes a middleware/web methods server 224 that hosts a variety offeatures related to administrative services management, contentmanagement, and application management described above. Themiddleware/web methods server 224 may, for example, manage businessrules (i.e., the relationships) between end users and suppliers based,in part, on contractual terms or other arrangements, as processedaccording to the price and file management feature. For example,supplier user-side business rules may, for example, designatepreferences regarding delivery terms (e.g., restrictions against odd lotsales, FOB preference, carrier preference, etc.), and price andinsurance terms (e.g., CIF preference, applicable sales tax, etc.).Similarly, end user-side business rules may, for example, designatepreferences regarding preferred suppliers, delivery terms (e.g., FOBpreference, default quantity, carrier preference, etc.), and price andinsurance terms (e.g., CIF preference, applicable sales tax, etc.). Atleast one advantage of implementing end user-side and supplier user-sidebusiness rules is the capability to generate customized purchase ordersin accordance with contractual or default business rules. Such purchaseorders are created by the invoke requisition/purchase orders feature,which is invoked via processing modules that are executed on the customdatabase servers 222. Middleware/web methods server 224 may applydefault ordering, sales, delivery, and other terms in the instance wherean end user and supplier user do not have existing contractual terms orother arrangements.

The middleware/web methods server 224, as well as the transactionprocessing server 223, implements the price and file management featureto access existing contracts between end users and suppliers. Thefeature is usually implemented as a component of the middleware/webmethods server 224, but may also be invoked via transaction processingmodules that are executed on the transaction processing servers.Contract management algorithms may also be implemented as a sub-featureof the price and file management feature. For example, the algorithmsare usually responsible for accessing, retrieving, and processing datafrom each respective end user and supplier that might have negotiated acontract. FIG. 10 illustrates an exemplary contracts management tool1000 that may be used to manage the contracts between an organizationand a supplier. The contract data is accessible by the transactionprocessing servers 223 and transaction database 238. Suppliers are ableto submit product prices and other product related data via the priceand file management feature. Furthermore, multiple pricing/currencyschemes can be created by suppliers for end user organizations and maybe based on contractual terms negotiated between end user organizationsand suppliers. Individual end users within the same organization, forexample, may be assigned different price/currency schemes that may bebased on different contractual terms with an individual supplier. Adesignated end user (e.g., a “contract manager”), akin to a super user,can be assigned the responsibility for managing and choosing the pricingschemes displayed to each individual end user within the organization.The designated end user may also be tasked with ranking the spendingthresholds for triggering a new price tier. Individual end users arecapable of accessing pricing schemes for supplier products where the endusers have been granted access by the designated end user or super user.By default, the lowest supplier pricing scheme available is firstdisplayed to the end user, although other pricing schemes may also beavailable and accessible.

The following algorithm, for example, may be implemented to determinewhich pricing scheme should be displayed to an individual end user.First, all pricing schemes for a specific product may be denoted asaccessible. A filter-type method may then be used to exclude pricingschemes denoted as inaccessible to the end user organization and, thus,allowing only accessible pricing schemes. Another filter-type method maybe used to determine which accessible pricing schemes, if any, arerelated to contracts negotiated between the end user organization andaccessible suppliers. If no pricing schemes are related to anycontracts, then a default/general pricing scheme is displayed to the enduser. Finally, if at least one pricing scheme is related to any relatedcontracts, then a filter-type method excludes those pricing schemesrelated to contracts deemed inaccessible to this end user, and permitsthe accessible pricing schemes to be displayed. The displayed accessiblepricing schemes would, however, be subject to the end user spendingthresholds, which may be set by a super user. When an end user invokesthe generation of a purchase/requisition order, the appropriate pricingscheme is referenced and can be based upon available contractual termswith the appropriate supplier.

An end user organization can manage pricing schemes such that distinctcontracts are assigned to specific end users or super users. The featureto manage pricing schemes is invoked via transaction processing modulesexecuted on the transaction processing servers 223. The specific endusers or super users have the ability to approve or reject contracts,and set extended dates. Moreover, supplier users have the ability tocreate multiple pricing/currency schemes that may be based oncontractual terms with end user organizations. Whether an individual enduser/organization is a constituent of a trade group, department, orother organization, may influence the pricing/currency schemedetermination. Supplier users can also have the ability to load singleor multiple pricing/currency schemes for end users within the same datasink (e.g., hosted supplier products catalog), which may later beprocessed by the price and file management feature and assigned to eachrespective end user. Moreover, end users can designate specific productsfrom supplier pricing/currency schemes as favorites. End user favoritescan be dynamically updated with the lowest available supplier pricingscheme.

The transaction processing servers 223 of the present invention mayexecute transaction processing modules that query, update, and/or createdata model instances within the transaction database 238. Moreover, endusers can also approve, request to modify, or reject supplier productswithin hosted catalogs, and can also assign and route specific supplierproducts to other appropriate end users for review, dependent upon enduser specific attributes like title within the organization. Forexample, certain end users may be able to access hazardous and/orexpensive supplier products, while other end users may not be able to doso based on their precedence/role within the end user organization.Similarly, certain end users may also have the ability to makehigh-volume orders, while others may not. The hosted supplier productscatalog 234 may be routinely updated by each supplier user at his/herdiscretion, or on a monthly, quarterly, or annual basis, and may containdata from suppliers such as, for example, custom product lists and enduser organization-specific prices/currencies.

FIG. 11A illustrates an exemplary cart and requisition tool 1100 inaccordance with the present invention. As shown in FIG. 11A, the cartand requisition tool 1100 includes an active cart 1140 for tracking theitems designated for purchase from the search results described above.In an exemplary embodiment illustrated in FIG. 11A, the active cart 1140includes requisition workflow tool 1110 that displays a live view of therequisition process for the items in the cart. For example, therequisition workflow tool 1110 displays the status of the requisitionfrom the point at which a product is added 1110 a, the cart is edited1110 b, the requisition is reviewed 1110 c, and the order is placed 1110f. The requisition workflow tool 1110 further displays a purchaserequisition approval step 1110 d as well as a purchase order previewstep 1110 e. Each of the status boxes 1110 a-1110 f of the requisitionworkflow tool 1110 may be invoked to activate the tool that manages thecorresponding status. For example, invoking the “Add Products” box 1110a (e.g., clicking on the box) activates the search engine to search foradditional products to be added to the cart 1140. Invoking the “EditCart” box 1110 b activates the active cart 1140 for editing the productsin the cart. Invoking the “Review” box 1110 c activates a summary of theproducts included in the requisition, including, for example, accountingcodes, billing and shipping addresses, and other customizable dataelements that may be configured by the user's organization. Invoking the“PR Approvals” box 1110 d displays the set of workflow/approval steps aninvoked requisition will be processed through prior to order creation.Invoking the “PO Preview” box 1110 e activates a list of purchase ordersthat are generated if the invoked requisition is approved. Invoking the“Place Order” box 1110 f submits the invoked requisition to the steps ofthe workflow/approval process.

Cart information 1120 such as cart name 1120 a, description 1120 b,priority 1120 c, and assigned approver 1120 d are also displayed and maybe edited. The cart information 1120 further includes supplier and lineitem details organized alphabetically, for example, according to eachsupplier's name, and lists each chosen product description, catalognumber, size and/or packaging data, unit price, quantity ordered, price,and currency. For each supplier there is also a corresponding suppliersubtotal that is calculated according to the total of products chosen bythe user.

FIG. 11B illustrates further details of the exemplary cart andrequisition tool 1100 in accordance with the present invention. Asshown, the cart and requisition tool 1100 includes a requisition reviewtool 1150, purchase request approval tool 1160, and purchase orderpreview tool 1170. As described above, the various status boxes (e.g.,1110 c-1110 e) in the requisition workflow tool 1110 activate thecorresponding tool 1150-1170. As shown in FIG. 11B, the requisitionreview tool 1150 displays information about the requisition being built.For example, as shown, the requisition review tool 1150 includes asummary page 1150 a that displays all the information regarding therequisition being reviewed, such as the general information, shippinginformation, billing information, accounting codes, internal/externalnotes and attachments, as well as supplier/line item details of theproducts in the cart 1140. All of the information shown in therequisition summary page 1150 a may be edited by invoking thecorresponding tool, such as the shipping/handling tool 1150 b, billingtool 1150 c, accounting code tool 1150 d, notes and attachment tool 1150e, supplier information tool 1150 f, and taxes/S&H pricing tool 1150 g.

For instance, the shipping/handling tool 1150 b may be used to set theshipping address of the products in the purchase order as well asdesignate delivery options, such as “expedite,” “shipping method,” and“requested delivery date.” The billing tool 1150 c may be used to setthe billing address and billing options, such as accounting dates. Theaccounting tool 1150 d may be used to designate the accountinginformation of the requisition, such as any fund/grant contacts,organization information, account numbers, product codes, activitysummaries, and location. The notes and attachments tool 1150 e may beused to designate any internal codes associated with the products in thepurchase order, such as custody codes and equipment codes used in theorganization. The supplier information tool 1150 f may be used to assignor modify supplier information for the products in the order, such ascontract information with the supplier, purchase order number, quotenumber, and purchase order clauses. The taxes/S&H tool 1150 g may beused to define the tax/S&H information related to purchases from aparticular supplier, such as tax percentage and/or S&H cost from totalpurchase price (e.g., 0% tax, free shipping if over $200 purchase,etc.).

FIG. 11C illustrates an exemplary purchase request approval tool 1160that corresponds to the purchase requisition approval step 1110 d inaccordance with the present invention. The exemplary purchase requestapproval tool 1160 graphically portrays the status of the requisitionbeing reviewed (e.g., submission of the purchase requisition 1160 a,financial approval 1160 b, supplier approval/processing 1160 c, LPO 1160d, purchase order creation 1160 e, and completion 11600. As with therequisition workflow tool 1110 (FIG. 11B), each workflow/approval stepstatus box may be invoked to activate a tool, corresponding to eachworkflow/approval step, to view the reason(s) underlying the workflowengine's invocation of that step. Other intervening or superseding stepsmay also be portrayed without departing from the scope of the presentinvention.

FIG. 11D illustrates an exemplary purchase order preview tool 1170 thatcorresponds to the purchase order preview step 1110 e in accordance withthe present invention. The purchase order preview tool 1170 permits theuser to preview the purchase orders that will be generated from thecurrent active cart 1140. The active cart 1140 corresponding to thatuser is queried and the preview purchase orders are displayed, as shown,in alphabetical order according to supplier name. Other methods ofordering or retrieving the purchase orders corresponding to the user mayalso be used without departing from the scope of the present invention.

With reference to FIG. 2, the feature to invoke purchase/requisitionorders may be hosted on the middleware/web methods servers 224 andmanaged by the eProcurement architecture of the present invention suchthat it is executed consistently with end user and supplier userbusiness rules as described above. From a high-level point-of-view, thisfeature is implemented based on whether the order information sought tobe processed by an end user is internal to the organization or supplierrelated. If the information is internal, it is processed accordingly viathe end user 212, the middleware/web methods servers 224, through to thecustom database servers 222, and then to the hosted supplier productscatalog 234; otherwise, the information is processed similarly exceptthat the appropriate supplier related databases (e.g., the masterproduct database 236, and the transaction database 238) may also beinvoked.

An auto purchase order feature is available via the middleware/webmethods servers 224 and is invoked via transaction processing modulesexecuted on the transaction processing server 223, and can populateentries of a purchase order in accordance with applicable end user andsupplier contractual terms. The auto purchase order feature allows forthe generation of distribution, and payment, rule-based purchase ordersbased on the customizations effectuated by a super user of theorganization in the manner described above. For example, the feature canautomatically insert legal terms (e.g., the right to cure productdefects, what constitutes rejection and/or revocation of an order, whatmay constitute a material defect, the seller's return policy, thebuyer's acceptance policy, etc.), as well as other non-legal terms andconditions (e.g., preferred delivery dates, shipping and handlinginstructions, appropriate contact/authorized personnel, payment andreceipt of payment instructions, etc.), based on a contract that may bein place between an end user organization and a supplier. If no contractis in place, then the auto purchase order feature may prompt the user orautomatically insert default terms and conditions, whether legal ornon-legal. The feature may create receipts for each end user initiatedtransaction/purchase order and add multiple transactions/purchase ordersto a single receipt. For capable suppliers, automated responses can beaccepted for display to the end user. Such automated responses mayinclude, for example, order acknowledgement and advanced shippingnotice. Also, a document search sub-feature allows searching anyexisting transactions/purchase orders. The auto purchase order featurealso supports supplier pricing schemes modeled using the U.S. Dollar aswell as all other currency types (e.g., Euro, Yen, Pound, Peso, etc.).

FIG. 12 illustrates an exemplary workflow setup tool in accordance withthe present invention. As shown, the workflow setup tool 1200 includesrequisition workflow tool 1210, purchase order setup tool 1220, andfulfillment setup tool 1230. These tools are used to setup variousaspects of the workflow process as described above. For example, asshown in FIG. 12, the purchase order setup tool 1220 may be used todesignate the names of approvers to review and approve purchase ordersfor a particular organization. As shown, the approver list may becustomized for different departments (e.g., Math), types of products(e.g., non-catalog item), and even for specific users. Similarly, therequisition setup tool 1210 and fulfillment setup tool 1230 may be usedto designate approvers for requests and fulfillment processes,respectively. Other workflow parameters may be further defined withoutdeparting from the scope of the present invention.

FIG. 13 illustrates an exemplary purchase order approval tool inaccordance with the present invention. As shown, purchase order searchengine 1310 searches through all of the purchase orders generated by theeProcurement system of the present invention for each of the hostedorganizations. The results of the search may be filtered based ondisplay criteria such as “Approver” (e.g., user responsible forapproving the document), “Approval Queues,” “All Pending Requisitions,”“Urgent Approvals,” “Unassigned Approvals,” “Future Approvals,” and“Manual Filter” options. The result list of the purchase orders aredisplayed in the display portion 1320 with such information as P.O.number, status of the P.O., priority level of the P.O., the date/time ofthe submission for approval, the name of the requester, the designatedsupplier, the amount, and selectable options. Using the purchase orderapproval tool, the approvers as well as the requisitioners may monitorthe status of the requests and ascertain where the request is in theworkflow process. Using the tools described above, the user may drilldown to the lowest level of the request to determine what needs to bedone to move the request along if it becomes bottlenecked in theprocess, for example.

At the conclusion of the ordering process, an approval/rejection oforders feature may be implemented also through the middleware/webmethods server 224, as well as the transaction processing server 223.The approve/reject order feature is invoked via a transaction processingmodule that is executed on the transaction processing servers 223. Thisfeature can be managed by the middleware/web methods server 224 suchthat it is executed consistently with end user and supplier userbusiness rules. For example, one advantage of this feature is itsability to provide notice of an approved or rejected order to an enduser or super user.

FIG. 14 illustrates an exemplary history tool in accordance with thepresent invention. The eProcurement system in accordance with thepresent invention keeps a history of all requests, purchase orders,receipts, invoices, and actions (e.g., edits to parameters) made in thesystem that may be searched and reviewed. History tool 1400, forexample, includes a tool to search for purchase order histories,purchase request histories, receipt histories, and invoice histories.The searches may be made by purchase order number, by requisition, bysupplier/SKU numbers, by receipts, by invoices, and by contracts. Theseparameters may be filtered by dates, users, as well as other specificsof the history being sought.

Finally, a supplier configuration feature may be implemented. Thisfeature allows for the capability to have a supplier master that hostsmultiple fulfillment centers. Also, this feature allows for an orderprocessing feature with multiple payment/currency methods for eachfulfillment center, the execution of shipping and handling rules, andorder distribution features. The order distribution features can includesuch features as facsimile or email confirmation, as well as otherdelivery methods, organized hierarchically to ensure purchase orderdelivery.

FIG. 15 is a block diagram 1500 of the electronic procurement system 20communicating over a network 16 with suppliers 214-A (to 214-N) andpurchasing organizations 212-A (to 212-N). The electronic procurementsystem 20 generally includes a supplier server application 1542 andpurchaser server application 1550, which may interface with the accessengine 21, contract engine 1554, search/catalog engine 22, requisitionengine 23 a, order/payment engine 23 b, tracking engine 23 c, andbusiness rules engine 24.

As described, business rules describe and control the relationshipsbetween end users and suppliers based, in part, on contractual terms orother arrangements, as processed according to the price and filemanagement feature. For example, supplier user-side business rules may,for example, designate preferences regarding delivery terms (e.g.,restrictions against odd lot sales, FOB preference, carrier preference,etc.), and price and insurance terms (e.g., CIF preference, applicablesales tax, etc.). Similarly, end user-side business rules may, forexample, designate preferences regarding preferred suppliers, deliveryterms (e.g., FOB preference, default quantity, carrier preference,etc.), and price and insurance terms (e.g., CIF preference, applicablesales tax, etc.). At least one advantage of implementing end user-sideand supplier user-side business rules is the capability to be able togenerate customized purchase orders, in accordance with contractual ordefault business rules.

Non-limiting examples of business rules include:

-   -   If the extended price of any line item exceeds the limit set in        a users profile, route to the users financial approver.    -   If the total value of the requisition exceeds the limit set in a        users profile, route to the users financial approver.    -   If a requisition sent to a user for financial approval exceeds        the users approval authority set in the users profile, route the        requisition to the users financial approver.    -   If the requisition contains suppliers classified by a users        organization as “IT Vendors,” send the requisition to the CIO.    -   Requisitions for the Math Department over $10,000 are routed to        the Vice Chancellor of Liberal Arts.    -   If any item on the PO is radioactive, route the PO to the        environmental health and safety (EH&S) Department for review and        approval.    -   If any item on the PO is classified as hazardous, notify the        EH&S Department. No approval is required.    -   If the account code for a line item on the requisition has a        budget, and the requisition will exceed the budget, route the        requisition to the Budget Manager.    -   If the user adds a non-catalog item to their requisition, route        it to the Purchasing Department to validate the information        entered.    -   If a requisition is marked for expediting, skip all rules and        route directly to the Purchasing Department.    -   All the above examples of business rules are exemplary and not        intended as limiting.

The supplier server application 1542 and purchaser server application1550 may also interface with the transaction engine 23, which mayinclude the requisition module 23 a, order/payment engine 23 b, and thetracking engine 23 c. Moreover, the supplier server application 1542 andpurchaser server application 1550 may send and receive data from thedata repository 30, which includes the user database 32, the productindex database 34, the product database 36, and the transaction database38. The engines may communicate via function/method calls, filelibraries, and database queries. The contract engine 1554 executes thenecessary functions for implementing the contract management feature,which manages and links new or existing procurement contracts, formedbetween buyer organizations and supplier organization, with a group. Forexample, a new or existing contract is initially stored in the contractsdatabase 3200 (as described in FIG. 32) and may routinely be updated inaccordance with amendments (e.g., extensions, additions of agreed uponterms, assignments, or the like) or other contractual events (e.g., theexpenditure of quantity/time/spending limits (i.e., tiers), pricefluctuations—e.g., rebates or price reductions, item changes oradditions, etc.); at such time intervals as determined by the contractengine 1554, the group is updated accordingly. The group includes, forexample, buyer users, supplier users, the business rules engine 24,items, forms, purchase requisitions/orders, sales orders/invoices, andbuyer invoices. Furthermore, the contract engine 1554 also supportscontract searching (as described in FIG. 10) based on specificuser-specified criteria like, for example, contract number, contractkeyword, or supplier/catalog name.

The supplier server application 1542 communicates with a supplier 214-A(to (214-N) over network 16 and the purchaser server application 1550communicates with a buyer 212-A (also referred to herein as a purchasingorganization) over network 16. A supplier user would use a clientapplication 1516-A (to 1516-N) to communicate with, generally, theelectronic procurement provider 20 and, specifically, the supplierserver application 1542. The client application 1516-A (to 1516-N) maybe a web-browser 1518-A (to 1518-N) for the supplier user to use, or maybe a standalone application. The web-browser 1518-A or standaloneapplication may display features to manage catalog(s) 1512-A (to 1512-N)and manage sales 1514-A (to 1514-N), which may be communicated via thesupplier server application 1542 and displayed to the supplier user. Abuyer user would use a client application 1532-A (to 1532-N) tocommunicate with, generally, the electronic procurement provider 20 and,specifically, the purchaser server application 1550. The clientapplication 1532-A (to 1532-N) may contain a web-browser 1538-A (to1538-N) for the buyer user to use, or may be a standalone application.The web-browser 1538-A or standalone application may display features tomanage purchasing 1533-A (to 1533-N), manage payment 1534-A (to 1534-N),manage users 1535-A (to 1535-N), manage privileges 1536-A (to 1536-N),and/or manage business rules 1537-A (to 1537-N), which may becommunicated via the purchaser server application 1550 and displayed toa buyer user. For example, a user that sends a request to the system 20that is outside the scope of that user's privileges would receive anappropriate denial response from the system 20 and, more specifically,for example, from the manage privileges 1536-A feature.

FIG. 16 is a block diagram 1600 of the buyer 212 communicating with thepurchaser server application 1550, located at the electronic procurementprovider 20, over a network 16, using a client app 1532 such as abrowser 1638, TCP/IP communications 1627, and/or a local application1618. The purchaser server engine 1650 may interface with or include thefollowing modules, or a subset thereof:

-   -   a catalog engine 1655 for managing each supplier catalog by        implementing features for uploading catalog data, linking to the        proper punch-out catalog(s) (1656) via the punch-out module 22 a        and back to the buyer, managing supplier showcase promotions and        overlays (1657), converting supplier catalog data into a common        data format (1658), search (1659), and interfacing with the        search engine 22 for searching the master product database or        other accessible database of the electronic procurement system        20;    -   an organization database 1660 for storing organization specific        information like, for example, business rules (1662),        user-related data (1663), or permissions (1664);    -   a currency engine 1670 for implementing multi-currency features        like, for example, normalizing a plurality of currency data        (1671) into a default or preferred currency, interfacing with        the search engine 22 to return item search results to a buyer        user who sent a request to organize/filter the search results        (1672) according to a specific currency, or determining the        default or preferred currency with which a supplier requests or        requires payment (1673); or    -   a workflow management engine 1680 for managing the flow of        purchase requisitions to the appropriate approver (via the        requisition fulfillment engine 1686) (which may be prioritized        via the prioritize receipt feature 1687 based on user hierarchy,        privileges, or business rules), sending the approved requisition        back to the appropriate buyer user (via the requisition        fulfillment engine 1686), interfacing with the search engine 22        to locate an appropriate requisition and/or purchase order (via        the search PO/Invoice feature 1692), forwarding a purchase order        to the appropriate supplier (via the requisition fulfillment        engine 1686), forwarding a sales order and/or invoice from the        supplier to the appropriate buyer user (via the order payment        engine 1690 and using the PO/Invoice match feature 1691 for        linking a purchase order on the buyer user side with an incoming        invoice from the supplier), or sending event updates to the        contract engine 1554 (via the contract management engine 1688).    -   Moreover, the workflow management engine 1680 may also interface        with a purchasing engine 1681 that receives orders (via an order        entry feature 1682), manage the items a buyer user places in a        cart or moves/assigns to a new cart (via a cart management        feature 1683), present alternative items to a buyer in lieu of        items chosen for requisitioning that are not available according        to privileges, inventory or a contractual agreement (via an        alternative item present feature 1684), or approve an order if        approved by the appropriate approver user (via an order approval        feature 1685). In addition, the workflow management engine 1680        may also interface with a form management engine 1693 for        receiving requisitions and orders via user-created custom forms        stored in a forms database 2300. Once received, the requisitions        and orders are then routed to approvers and suppliers,        respectively, according to workflow business rules. And, the        workflow management engine 1680 also interfaces with the catalog        management feature 1695 for retrieving item data related to the        items present in the requisitions, orders, or invoices being        processed by the workflow management engine 1680.

FIG. 17 is a block diagram 1700 of the supplier 214 communicating withthe supplier server application 1542, located at the electronicprocurement provider 20, over a network 16, using a client app 1516 suchas a browser 1518, TCP/IP communications 1727, and/or a localapplication 1718. The supplier server engine 1750 may interface with orinclude the following modules, or a subset thereof:

-   -   a catalog engine 1755 for managing each supplier catalog by        implementing features for uploading catalog data, linking to the        proper punch-out catalog(s) (1756) via the punch-out module 22 a        and back to the buyer, managing supplier showcase promotions and        overlays (1757), converting supplier catalog data into a common        data format (1758), and interfacing (1759) with the catalog        management feature 1695 for updating the master product database        or other accessible supplier-related database of the electronic        procurement system 20;    -   an item database 1790 for storing item specific information        like, for example, item description (1791), price and quantity        available (1792), restrictions (1793), or priorities (1794);    -   a supplier database 1775 for storing supplier specific        information like, for example, detailed supplier data (1776), or        supplier catalog data (1777); or    -   a sales management engine 1760 for managing the flow of sales        orders and sales invoices from the appropriate buyer to the        appropriate supplier (via the sale fulfillment engine 1770)        (which may be prioritized (via the prioritize customer feature        1771) based on buyer/user hierarchy, privileges, or business        rules), shipping (1772) and tracking (1773) the ordered item(s)        to the appropriate buyer, interfacing with the search engine 22        to locate an appropriate purchase order and/or invoice (via the        search PO/Invoice feature 1782), forwarding an invoice to the        appropriate buyer (via the sale fulfillment engine 1770),        receiving payment on an invoice from a buyer to the appropriate        supplier (via the receive payment engine 1780 and using the        PO/Invoice match feature 1781 for linking a sales order on the        supplier user side with an outgoing invoice from the supplier),        or sending event updates to the contract engine 1554 (via the        contract management engine 1784).    -   Moreover, the sales management engine 1760 may also interface        with a sales engine 1761 that receives sales orders (via an sale        entry feature 1762), manage the items (e.g., goods and/or        services) a buyer user requested via the sales order (via a        goods management feature 1763), present alternative items to a        buyer in lieu of items chosen for ordering that are not        available according to inventory or business rules like a        contractual agreement (via an alternative item present feature        1764), or approve a sales order if the item(s) is available and        complies with business rules (via a sale approval feature 1765).        In addition, the workflow management engine 1680 may also        interface with a form management engine 1783 for receiving sales        orders via user-created custom forms stored in a forms database        2300. Once received, the sales orders are then routed to the        appropriate supplier user(s), respectively, according to        workflow business rules. Then, the process of fulfilling the        order is initiated and managed by the sales fulfillment engine        1770.

FIG. 18 is a block diagram 1800 of a supplier client 214. The clientapplication 1516 may be a web-browser 1518 for the supplier user to use,or may be a standalone application. The web-browser 1518 or standaloneapplication may display features for:

-   -   managing catalog(s) 1512;    -   managing sales 1514;    -   interfacing with the catalog database 1820 to, for example,        input or view item restrictions 1821, or to make catalog updates        1822;    -   managing forms 1825 by, for example, customizing required forms        1826;    -   managing sales 1830 (e.g., via a sales engine 1831) by, for        example, entering sales data 1833, approving sales 1834,        fulfilling sales orders 1835, and addressing disputes that may        arise 1836; or    -   processing invoices and payments 1840 by, for example, sending        invoices 1841, matching purchase orders to invoices 1842, or        processing funds 1843.

FIG. 19 is a block diagram 1900 of a purchasing organization client 212.The client application 1532 may be a web-browser 1538 for the buyer userto use, or may be a standalone application. The web-browser 1538 orstandalone application may display features to manage purchasing 1533,manage payment 1534, manage users 1535, manage privileges 1536, ormanage business rules 1537. In addition, the web-browser 1538 orstandalone application may also display features for:

-   -   interfacing with the user database 1920 to, for example, access        or define user privileges 1921;    -   managing a buyer organization's business rules 1925 to, for        example, define preferred suppliers 1926, items 1927, or        catalogs 1928;    -   managing workflows 1930 like, for example:        -   the flow of purchase requisitions within the buyer            organization,        -   access to catalogs 1932 as may be necessary (via a purchase            engine 1931) for forwarding a purchase requisition or order            appropriately for approval,        -   order entry 1933, order approval 1934, order fulfillment            1935 (all via a purchase engine 1931), or        -   forwarding a sales order and/or invoice from the supplier to            the appropriate buyer user (via the payment engine 1940 and            using the PO/Invoice match feature 1942 for linking a            purchase order on the buyer user side with an incoming            invoice from the supplier), processing payment on the            order's invoice 1941 (via the payment engine 1940), or            forwarding of a user-customized form in accordance with            business rules (via form management 1943).

FIG. 20 is a block diagram of a server system 2000. The server system2000 generally includes one or more processing units (CPU's) 2002, oneor more network or other communications interfaces 2004, memory 2010,and one or more communication buses 2008 for interconnecting thesecomponents. The communication buses 2008 may include circuitry(sometimes called a chipset) that interconnects and controlscommunications between system components. The server system 2000 mayoptionally include a user interface, for instance a display 2006 and aninput device 2005. Memory 2010 may include high speed random accessmemory and may also include non-volatile memory, such as one or moremagnetic disk storage devices. Memory 2010 may include mass storage thatis remotely located from the central processing unit(s) 2002. Memory2010 includes high-speed random access memory, such as DRAM, SRAM, DDRRAM or other random access solid state memory devices; and may includenon-volatile memory, such as one or more magnetic disk storage devices,optical disk storage devices, flash memory devices, or othernon-volatile solid state storage devices.

In some embodiments, memory 2010 stores the following programs, modulesand data structures, or a subset thereof:

-   -   an operating system 2011 that includes procedures for handling        various basic system services and for performing hardware        dependent tasks;    -   a network communication module 2012 that is used for connecting        the server system 2000 to other computers via the one or more        communication network interfaces 2004 (wired or wireless) and        one or more communication networks, such as the Internet, other        wide area networks, local area networks, metropolitan area        networks, and so on;    -   a catalog module 2020 that provides information and prices about        products in hosted supplier product catalogs;    -   databases 2032;    -   a staging database 2034;    -   a currency module 2040;    -   a sales/purchase management module 2046;    -   a contract management module 2060;    -   a database and management module 2070; and    -   auxiliary services modules 2090.

The catalog module 2020 may include the following modules, or a subsetthereof:

-   -   supplier catalog access module 2022 for providing suppliers with        access to their respective hosted supplier product catalogs;    -   a user local catalog create/access module 2024 for providing        users (purchasing organizations) with local catalogs, in one        embodiment generated by the respective users, from which the        users can order products from suppliers who are not associated        with hosted supplier product catalogs. In one embodiment, a        supplier in the local catalogs is a local service provider (e.g.        catering or a limousine service) from which a user wants to        order products and services using the electronic procurement        system;    -   a schema translate module 2026 for translating catalog data        provided by suppliers or purchasing data provided by users into        a common format associated with the electronic procurement        system;    -   a schema update module 2028 for updating data in the common        format associated with the electronic procurement system in        response to changes in the respective catalog data or purchasing        data; and    -   a supplier showcase module 2030 for promoting certain suppliers        to users of a purchasing organization, which in an embodiment        may be performed according to business rules.

The databases 2032 may include all databases used by the system. Thesedatabases may in one embodiment be stored as logical partitions in amemory. These databases may in another embodiment be stored as tables ina larger database. These databases may in yet another embodiment bestored in separate memory or storage devices.

The staging database 2034 may comprise a catalog development environment(i.e., a staging area) for catalogs associated with suppliers. The datain the staging area may include complete catalogs, incomplete catalogsin development, partially uploaded catalogs, etc. A supplier can chooseto make any or all portions of their respective catalog(s) in thestaging database ‘live’ by syndicating the respective portions. A livecatalog is one from which a user or purchasing organization may orderitems. The item database 2036, which may be a subset of the stagingdatabase 2034, contains descriptions, characteristics, price, picturesand other pertinent information for items listed in the catalogs.

The currency module 2040 may include the following modules, or a subsetthereof:

-   -   a normalize rates module 2042 for normalizing currency rates        visible by a purchaser of goods and/or services, purchasing from        suppliers using different currencies to that of the purchaser,        or by a supplier of goods and services selling to purchasers        using different currencies to the supplier; and    -   a filter by currency module for allowing purchasers to filter        suppliers according to currencies they do business in, or        allowing suppliers to filter purchasers similarly.

The sales/purchase management module 2046 may include the followingmodules, or a subset thereof:

-   -   a template management module 2048, for managing templates used        by suppliers or purchasers of the system in placing orders for        goods or services;    -   a cost/markup management module 2050 for determining        characteristics (e.g., average cost) of inventory and managing        the inventory based on the characteristics and a markup rate;    -   order receipt module 2052 for determining that an order has been        received, and preparing to fulfill the order;    -   sale fulfillment module 2054 for fulfilling the order, including        invoicing and shipping goods to the purchaser; and    -   a receive payment module 2056 for receiving payment associated        with an order (both for fulfilled and unfulfilled orders).

The contract management module 2060 may include the following modules,or a subset thereof:

-   -   order receipt module for 2062 for determining that an order has        been received and matching the order to a contract;    -   sale fulfillment module 2064 for associating fulfillment of an        order with a contract and verifying that the received order        complies with the contract;    -   receive payment module 2066 for associating payments with a        contract and verifying that appropriate discounts and terms of        the contract are reflected in the payment;    -   associate contract with forms module 2068 for associating the        contract with forms used by a supplier or purchaser, such that        terms of the contract apply to the form.

The database and management module 2070 may include the followingmodules, or a subset thereof:

-   -   Access, update and manage database module 2072 for accessing,        updating and managing databases in the system, including:        -   user (purchaser) and supplier module 2074, for managing user            database 32 as described, which is accessed by a buyer user            12 or supplier user 14 through access module 21 as            described;        -   workflow, catalog and forms module 2076, for managing            workflow database 3000, catalog database 2400, and forms            database 2300 as described;        -   master, transaction and contracts module 2078, for managing            master database 236, transaction database 238 and contracts            database 3200 as described;        -   staging module 2080, for managing staging database 3100 as            described;        -   invoice, purchase order, order, and requisition module 2082,            for managing invoice databases 3300 and 3400, order database            2900 and 2500, requisition database 2700 as described.

The auxiliary services module may include additional features orservices related to operation, management, security, authentication,maintenance or other aspects of the electronic procurement system.

FIG. 21 is a block diagram of a server system 2100. The server system2100 generally includes one or more processing units (CPU's) 2102, oneor more network or other communications interfaces 2104, memory 2110,and one or more communication buses 2108 for interconnecting thesecomponents. The communication buses 2108 may include circuitry(sometimes called a chipset) that interconnects and controlscommunications between system components. The system 2100 may optionallyinclude a user interface, for instance a display 2106 and an inputdevice 2105. Memory 2110 may include high speed random access memory andmay also include non-volatile memory, such as one or more magnetic,optical, or solid state disk storage devices. Memory 2110 may includemass storage that is remotely located from the central processingunit(s) 2102. Memory 2110 includes high-speed random access memory, suchas DRAM, SRAM, DDR RAM or other random access solid state memorydevices; and may include non-volatile memory, such as one or moremagnetic disk storage devices, optical disk storage devices, flashmemory devices, or other non-volatile solid state storage devices.

In some embodiments, memory 2110 stores the following programs, modulesand data structures, or a subset thereof:

-   -   an operating system 2111 that includes procedures for handling        various basic system services and for performing hardware        dependent tasks;    -   a network communication module 2112 that is used for connecting        the server 2000 to other computers via the one or more        communication network interfaces 2004 (wired or wireless) and        one or more communication networks, such as the Internet, other        wide area networks, local area networks, metropolitan area        networks, and so on;    -   a web browser 2118 or other tool for providing client access and        visibility to the electronic procurement system, where in some        embodiments some or all of the operations of the electronic        procurement system are performed at a server, and in some        embodiments some of the operations of the electronic procurement        system are performed at the client;    -   a catalog module 2120 that provides information and prices about        products in hosted supplier product catalogs;    -   databases 2132;    -   a workflow module 2142;    -   a currency module 2154;    -   a contract management module 2160;    -   a database management module 2170; and    -   auxiliary services modules 2184.

The catalog module 2120 may include the following modules, or a subsetthereof:

-   -   a user local catalog create/access module 2122, in some        embodiments similar to module 2024, for providing users        (purchasing organizations) with local catalogs, in one        embodiment generated by the respective users, from which the        users can order products from suppliers who are not associated        with hosted supplier product catalogs. In one embodiment, a        supplier in the local catalogs is a local service provider (e.g.        catering) from which a user wants to order products and services        using the electronic procurement system;    -   a supplier showcase module 2124, in some embodiments similar to        module 2030, for promoting certain suppliers to users of a        purchasing organization, which in an embodiment may be performed        according to business rules;    -   a Punch Out module 2126 for providing access to a catalog or        website separate from the hosted supplier product catalogs, and        allowing a purchaser to purchase an item from that catalog or        website, and process the purchase through the electronic        purchasing system;    -   a present alternatives module 2128, for presenting alternative        items to a prospective purchaser upon determining that an item        requested by the purchaser cannot be fulfilled or that a better        item might be available; and    -   a purchaser priority module 2130 for prioritizing purchasers or        purchaser orders associated with a user or purchasing        organization.

The databases 2132 may include all databases used by the system, both onthe server side and client side. These databases may in one embodimentbe stored as logical partitions in a memory. These databases may inanother embodiment be stored as tables in a larger database. Thesedatabases may in yet another embodiment be stored in separate memory orstorage devices. The databases may include the following databases ormodules, or a subset thereof:

-   -   business rules database 2134 for storing business rules        associated with a user, purchasing organization or supplier,        wherein in some embodiments the business rules may be set by a        super-user or administrator associated with an organization;    -   user privilege database 2136 for storing privileges associated        with users, such as purchasing privileges, approval privileges,        etc.;    -   organization priority database 2138 for storing priority        information associated with users or purchasing organizations in        the electronic procurement system; and    -   user created forms/search database 2140 for storing forms,        search queries, etc associated with a user or purchasing        organization, or associated with a supplier.

The workflow module 2142 may include the following modules, or a subsetthereof:

-   -   cart management module 2144 for allowing a user or organization        to manage a shopping cart associated with the purchase of items;    -   assign/move/schedule cart module 2146 for allowing a user or        organization to assign a cart to another user, to move items        from one cart to another (including a new) cart, and to schedule        a cart for purchasing;    -   purchasing/checkout module 2148 for allowing a user to checkout        one or more carts and purchase the items in the one or more        carts;    -   order fulfillment module 2150 for verifying that an order has        been received and processed for fulfillment, wherein in some        embodiments this may be similar to sale fulfillment module 2054        for fulfilling the order; and    -   payment module/currencies 2152 for processing payment for an        order, including converting currencies if necessary.

The currency module 2154 may include the following modules, or a subsetthereof:

-   -   a normalize rates module 2156 (in some embodiments similar to        module 2042) for normalizing currency rates visible by a        purchaser of goods and/or services, purchasing from suppliers        using different currencies to that of the purchaser, or by a        supplier of goods and services selling to purchasers using        different currencies to the supplier; and    -   a filter by currency module 2158 (in some embodiments similar to        module 2044) for allowing a purchasers to filter suppliers        according to currencies they do business in, or allowing        suppliers to filter purchasers similarly.

The contract management module 2160 may include the following modules,or a subset thereof:

-   -   an order receipt module 2162 (in some embodiments similar to        module 2062) for determining that an order has been received and        matching the order to a contract;    -   a sale fulfillment module 2164 (in some embodiments similar to        module 2064) for associating fulfillment of an order with a        contract and verifying that the received order complies with the        contract;    -   a receive payment module 2166 (in some embodiments similar to        module 2066) for associating payments with a contract and        verifying that appropriate discounts and terms of the contract        are reflected in the payment; and    -   an associate contract with forms module 2168 (in some        embodiments similar to module 2068) for associating the contract        with forms used by a supplier or purchaser, such that terms of        the contract apply to the form.

The database management module 2170 may include the following modules,or a subset thereof:

-   -   Access, update and manage database module 2172 (in some        embodiments similar to module 2072) for accessing, updating and        managing databases in the system, including:        -   user (purchaser) and supplier module 2174 for managing user            database 32 as described, which is accessed by a buyer user            12 or supplier user 14 through access module 21 as            described;        -   workflow, catalog and forms module 2176 for managing            workflow database 3000, catalog database 2400, and forms            database 2300 as described;        -   master, transaction and contracts module 2178 for managing            master database 236, transaction database 238 and contracts            database 3200 as described;        -   staging module 2180 for managing staging database 3100 as            described; and        -   an invoice, purchase order, order, requisition module 2182            for managing invoice databases 3300 and 3400, order database            2900 and 2500, requisition database 2700 as described.

The auxiliary services modules 2184 (in some embodiments similar tomodule 2090) may include additional features or services related tooperation, management, security, authentication, maintenance or otheraspects of the electronic procurement system.

FIG. 22 shows a top level data structure 2200 at an electronicprocurement provider server. The data structure includes data repository230, end user database 232, hosted supplier product index 234, masterproduct database 236, and transaction database 238. The end userdatabase 232 may in an embodiment include user/security database 3500.The hosted product index 234 may in an embodiment include summary searchdatabase 2460. The data structure further includes staging database3100, and scheduler database 3600.

The master database is associated with (and may in some embodimentsinclude one or more of) a forms database 2300 and a catalog database2400, which in an embodiment includes items database 2401 and pricesdatabase 2430.

The transaction database is associated with (and may in some embodimentsinclude one or more of) buyer invoice database 3300, sales invoicedatabase 3400, requisition database 2700, receipt database 2800, salesorder database 2900, workflow database 3000, contracts database 3200,and purchase order database 2500. The purchase order database 2500 mayin an embodiment include the fax database 2600, revisions database 2602,and distribution database 2604.

FIG. 23 shows a database diagram 2300 including the master database 236,with master database index 237 indexing into the master database. Masterdatabase index 237 includes summary search database 2460.

In an embodiment, forms database 2300 includes one or more of:

-   -   Form Config Section Title Help 2301, in some embodiments help        information for configuring a form section title;    -   Form Config Group Title Help 2302, in some embodiments help        information for configuring a form group title;    -   Form Config Element Title Help 2303, in some embodiments help        information for configuring a form element;    -   Form List 2304, in some embodiments a list of forms;    -   Form Config Section 2305, in some embodiments configuration of a        form section;    -   Form Config Group 2306, in some embodiments configuration of a        form group;    -   Form List Value 2307;    -   Form Config Element 2308, in some embodiments configuration of a        form element;    -   Form Config Version 2309, in some embodiments configuration of a        form version;    -   Form User Defined Fields 2310, in some embodiments user defined        fields in a form;    -   Form User Defined Field Config Parameters 2311, in some        embodiments parameters for configuring user defined fields in a        form;    -   Form List Value Title Help 2312;    -   Form 2313;    -   Form Audit Trail 2314, in some embodiments a list of changes to        a form for auditing purposes;    -   Forms User Defined Field Data 2315;    -   Forms Up Dist Method 2316, in some embodiments forms update        distribution method details; and    -   Forms Up Dist Method Data 2317, in some embodiments forms update        distribution method data.

FIG. 24 shows a database diagram 2400 including the master database 236,with master database index 237 indexing into the master database. Masterdatabase index 237 includes summary search database 2460.

As described, the search architecture is based upon an indexed,tokenized-type implementation. This search architecture may include asearch engine and a tokenization feature, both of which are invoked viaprocessing modules executed on the custom database servers. Productelements such as the product name, industry, price, and availability,among others, are primarily used to generate a product search index(e.g., a token). The process of generating a product search index/tokenis called “tokenization” and may be executed by a tokenization featureinvoked via a processing module. The indices/tokens generated as aresult of the tokenization feature, which relate to various products ofa multitude of suppliers, may be stored within and executed on thehosted supplier products catalog. Searching is actually executed againstwhat are termed as “verticals.” A vertical is designed similar to adrill-down menu architecture that consists of root nodes and leaf nodes,which are children of their respective roots.

The forms database 2300, and catalog database 2400 are associated withthe master database. The catalog database includes items database 2401and price database 2430.

In an embodiment, items database 2401 includes one or more of thefollowing:

-   -   Item Attribute Attr Value 2402, in some embodiments a value for        an item attribute;    -   Item Attribute Valid Values 2404, in some embodiments valid        values value for an item attribute;    -   Item Attribute Audit Trail 2406, in some embodiments a list of        changes to an item attribute for auditing purposes;    -   Item Attribute Definition 2408;    -   Item Attribute Data 2410;    -   Item 2412;    -   Chem Structure 2414, in some embodiments a description of a        chemical structure that may be ordered through the procurement        system;    -   Chem Structure Supplier 2416, in some embodiments a supplier of        a chemical structure;    -   Item Chemical 2418, in some embodiments a commercial item of a        chemical structure, e.g., a container of a certain chemical        structure.    -   Supplier 2420;    -   Item Image Description 2422, in some embodiments a description        of an image or picture associated with an item;    -   Item Image File Data 2424, in some embodiments an image data        file (e.g., a JPEG image or GIF image, as commonly used in web        applications);    -   Item Inventory Config 2426, in some embodiments data for        configuring inventory of an item; and    -   Item Inventory Config Audit Trail 2428, in some embodiments a        list of changes to data for configuring inventory of an item.

In an embodiment price database 2430 includes one or more of thefollowing:

-   -   Item 2432, in some embodiments an item for which a price is        stored in the price database;    -   Supplier 2434, in some embodiments a supplier associated with        the item;    -   Item Attribute Audit Trail 2436, in some embodiments a list of        changes to an attribute associated with an item, for which a        price is stored in the price database;    -   Price Set Org Details 2438, in some embodiments details of an        organization price;    -   Price Set 2440, in some embodiments a price for the item;    -   Price Version Approval 2442, in some embodiments approval for a        version of a price associated with the item;    -   Price Version 2444, in some embodiments a version of a price        associated with the item;    -   Price Set Version 2446;    -   Price 2448, in some embodiments a price for the item;    -   Submission Price Component 2450;    -   Price Version Loading Submission 2452;    -   Submission Audit Trail 2454, in some embodiments for auditing        submissions; and    -   Submission 2456.

In an embodiment summary search database 2460 includes one or more ofthe following:

-   -   Supplier Price Date 2462, in some embodiments a date associated        with a supplier price;    -   Supplier Content Date 2464, in some embodiments a date        associated with supplier content (e.g., description);    -   Organization 2466;    -   Supplier 2468, in some embodiments a supplier of an item;    -   Searchable Verticals By Rule 2470, in some embodiments        supporting rule-based searching;    -   Product Rule 2472, in some embodiments a rule related to a        product;    -   Product Vertical 2474, in some embodiments supporting        product-based searching;    -   Org Supplier Item Counts 2476, in some embodiments a count of        items stored at an organization supplier;    -   Product Category 2478, in some embodiments a category related to        a product;    -   Supplier Category Summary 2480, in some embodiments a summary of        a supplier category;    -   Item Incr Indexing Queue 2482, in some embodiments a queue for        incrementally indexing items;    -   Org Favorites Full Indexing Queue 2484, in some embodiments a        full-indexing queue for organizational favorites; and    -   Org Favorites Incr Indexing Queue 2486, in some embodiments an        incremental-indexing queue for organizational favorites.

FIG. 25 shows a database diagram 2500 including the transaction database228, with transaction database index 229 indexing into the transactiondatabase 228. Transaction database 228 is associated with (and in someembodiments includes one or more of) the following databases:

-   -   Purchase Order (PO) DB 2500, in some embodiments a database of        purchase orders;    -   Fax DB 2600, in some embodiments a database of faxes;    -   Distribution DB 2602, in some embodiments for storing order        distributions, where the order distribution features can include        such features as facsimile or email confirmation, as well as        other delivery methods, organized hierarchically to ensure        purchase order delivery, as described;    -   Revisions DB 2604, in some embodiments for storing revisions to        sales or purchase documents;    -   Buyer Invoice DB 3300, in some embodiments for storing buyer        invoices;    -   Seller Invoice DB 3400, in some embodiments for storing seller        invoices;    -   Requisition DB 2700, in some embodiments for storing purchase        requisitions;    -   Receipt DB 2800, in some embodiments for storing receipts;    -   Sales Order DB 2900, in some embodiments for storing sales        orders;    -   Workflow DB 3000, in some embodiments for storing workflow data        relating to sales, purchases and transactions, etc.; and    -   Contracts DB 3200, in some embodiments for storing contracts.

In an embodiment, Purchase Order (PO) DB 2500 includes one or more of:

-   -   Config Section Title Help 2502, in some embodiments help        information for configuring a section title;    -   PO Config Group Title Help 2504, in some embodiments help        information for configuring a purchase order group title;    -   PO Config Element Validation 2506, in some embodiments        validation information for configuring a purchase order element;    -   PO Audit Trail 2508, in some embodiments a purchase order audit        trail;

PO WF Activity History 2510, in some embodiments a purchase orderworkflow activity history;

-   -   PO Config Group 2512, in some embodiments configuration of a        purchase order group;    -   PO Config Section 2514, in some embodiments configuration of a        purchase order section;    -   PO Config Element 2516, in some embodiments configuration of a        purchase order element;    -   PO Config Version 2518, in some embodiments configuration of a        purchase order version;    -   PO Config 2520, in some embodiments configuration of a purchase        order;    -   PO Summary 2522, in some embodiments a purchase order summary;    -   PO Dist Method Data 2524, in some embodiments data for a        purchase order distribution method;    -   PO Dist Method 2526, in some embodiments a purchase order        distribution method;    -   PO 2528, in some embodiments a purchase order;    -   PO Currency Exchange Rates 2530;    -   Supplier 2532;    -   Fulfillment Center 2534;    -   PO User Selected Approver 2536, in some embodiments a        user-selected approver for a purchase order;    -   PO Pending Actions 2538, in some embodiments pending actions        relating to a purchase order;    -   PO PO Clauses 2540, in some embodiments clauses relating to a        purchase order;    -   PO Line Search 2542, in some embodiments line search details        relating to a purchase order;    -   PO Line 2544, in some embodiments a line of a purchase order;    -   Req Line Address 2546, in some embodiments an address line        relating to a purchase requisition;    -   PO Line Product 2548, in some embodiments a product line        relating to a purchase order;    -   PO Credit Card 2550, in some embodiments a credit card        associated with a purchase order;    -   PO Line Report 2552, in some embodiments a report line relating        to a purchase order;    -   PO CF Value Set Values 2556, in some embodiments to set the        value of a custom field value in a purchase order;    -   PO CF Value Set Ctxt 2558, in some embodiments to set the        context of a custom field value in a purchase order;    -   PO CF Value Set Def 2560, in some embodiments to set the        definition of a custom field value in a purchase order; and    -   PO User Selected Approver 2562, in some embodiments a        user-selected approver of the purchase order.

FIG. 26 shows a database diagram 2600 including the transaction database228, with transaction database index 229 indexing into the transactiondatabase. The fax database 2600, distribution database 2602 andrevisions database 2604 are associated with the transactions database228.

In an embodiment, the fax database 2600, distribution database 2602 andrevisions database 2604 include one or more of:

-   -   PO Fax Config Section 2610, in some embodiments configuration of        a purchase order fax section;    -   PO Fax Config Group 2612, in some embodiments configuration of a        purchase order fax group;    -   PO Fax Config Element 2614, in some embodiments configuration of        a purchase order fax element;    -   PO Fax Config 2616, in some embodiments configuration of a        purchase order fax;    -   PO Fax Config Version 2618, in some embodiments configuration        version of a purchase order fax;    -   PO Revision Document Relationship 2620, in some embodiments a        document relationship of a purchase order revision    -   PO Revision 2622, in some embodiments a purchase order revision;    -   PO Dist Request 2624, in some embodiments a purchase order        distribution request;    -   PO Dist Entry Data 2626, in some embodiments purchase order        entry data;    -   PO Revision Document 2628, in some embodiments a purchase order        document revision;    -   PO Dist Entry 2630, in some embodiments entry of a purchase        order distribution;    -   PO Dist Failure 2632, in some embodiments failure of a purchase        order distribution;    -   PO Dist Service Lock 2634, in some embodiments locking of a        purchase order distribution service; and    -   PO Dist Service Instance 2636, in some embodiments an instance        of a purchase order distribution service.

FIG. 27 shows a database diagram 2700 including the transaction database228, and requisition database 2700 associated with the transactiondatabase.

In an embodiment, requisition database 2700 includes one or more of:

-   -   Req Config Section Title Help 2702, in some embodiments help        information for configuring a purchase requisition section        title;    -   Req Config Group Title Help 2704, in some embodiments help        information for configuring a purchase requisition group title;    -   Req Config Element Validation 2706, in some embodiments help        information for configuring a purchase requisition element        validation;    -   Req Config Section 2708, in some embodiments configuration of a        purchase requisition section;    -   Req Config Group 2710, in some embodiments configuration of a        purchase requisition group;    -   Req Config Element 2712, in some embodiments configuration of a        purchase requisition section element;    -   Req Config 2714, in some embodiments configuration of a purchase        requisition;    -   Req Config Version 2716, in some embodiments configuration of a        purchase requisition version;    -   Req File Data 2718, in some embodiments purchase requisition        file data;    -   Req Currency Exchange Rates 2720, in some embodiments purchase        requisition currency exchange rates;    -   Req Sup Dist Method Data 2722, in some embodiments data for a        purchase requisition distribution method;    -   Req Sup Dist Method 2724, in some embodiments a purchase        requisition distribution method;    -   Req WF Activity History 2726, in some embodiments purchase        requisition workflow activity history;    -   Req Audit Trail 2728, in some embodiments changes to a purchase        requisition for auditing purposes;    -   Req Summary 2730, in some embodiments a summary of a purchase        requisition;    -   Requisition 2732;    -   Req WF Activity Buffer 2734, in some embodiments a purchase        requisition workflow activity buffer;    -   Req User Selected Approver 2736, in some embodiments a purchase        requisition user-selected approver;    -   Supplier 2738;    -   Fulfillment Center 2740, in some embodiments a fulfillment        center for a purchase requisition;    -   Req Supplier Group 2742, in some embodiments a supplier group        for a purchase requisition;    -   Req Punchout Session 2744, in some embodiments a punchout        session for a purchase requisition;    -   Req CF Value Set Def 2746, in some embodiments for setting a        definition of a purchase requisition custom field value;    -   Req CF Value Set Ctxt 2748, in some embodiments for setting a        context of a purchase requisition custom field value;    -   Req CF Value Set Values 2750, in some embodiments for setting a        value of a purchase requisition custom field value;    -   Contract 2752;    -   Req Line Address 2756, in some embodiments an address line for a        purchase requisition;    -   Req Line Address Field 2758, in some embodiments an address        field line for a purchase requisition;    -   Req Line 2760, in some embodiments a line for a purchase        requisition;    -   Req Line Product 2762, in some embodiments a product line for a        purchase requisition;    -   Req Credit Card 2764, in some embodiments a credit card for a        purchase requisition;    -   Req Line Report 2766, in some embodiments a report line for a        purchase requisition;    -   Req Line Search 2768; in some embodiments a search line for a        purchase requisition; and    -   Req File Description 2770, in some embodiments a file        description for a purchase requisition.

FIG. 28 shows a database diagram 2800 including the transaction database228, and receipt database 2800 associated with the transaction database.

In an embodiment, receipt database 2800 includes one or more of:

-   -   Supplier 2802, in some embodiments a supplier for a receipt;    -   Receipt 2804;    -   Receipt Currency Exch Rates 2806, in some embodiments currency        exchange rates associated with a receipt;    -   Receipt PO Relship 2808, in some embodiments a relationship        between a purchase order and a receipt;    -   Receipt Summary 2810, in some embodiments a summary of a        receipt;    -   Req Line Address 2812, in some embodiments an address line for a        purchase requisition;    -   Receipt Line 2814;    -   General Product 2816; and    -   Receipt Line Inventory Replenishment 2818, in some embodiments        an inventory replenishment line for a receipt.

FIG. 29 shows a database diagram 2900 including the transaction database228, and sales order database 2900 associated with the transactiondatabase.

In some embodiments, the transaction database 228 and sales orderdatabase 2900 are accessed by transaction processing servers 223 andmiddleware/web methods servers 224.

In an embodiment, sales order database 2900 includes one or more of:

-   -   Order Config Section Title Help 2901, in some embodiments help        information for configuring a sales order section title;    -   Order Config Group Title Help 2902, in some embodiments help        information for configuring a sales order group title;    -   Order Config Element Validation 2903, in some embodiments        validation for configuring a sales order element;    -   Order File Description 2904;    -   Order File Data 2905;    -   Order Config Group 2906, in some embodiments configuration of a        sales order group;    -   Order Config Section 2907, in some embodiments configuration of        a sales order section;    -   Order Config Element 2908, in some embodiments configuration of        a sales order element;    -   Order Config Version 2909, in some embodiments configuration of        a sales order version;    -   Order Config 2910;    -   Order Summary 2911;    -   Order PO Clause 2912, in some embodiments a purchase order        clause;    -   Order Audit Trail 2913, in some embodiments changes for auditing        a sales order;    -   Order 2914;    -   Order WF Activity History 2915, in some workflow activity        history for a sales order;    -   Order CF Value Set Values 2916, in some embodiments values for a        sales order custom field;    -   Order CF Value Set Ctxt 2917, in some embodiments context for a        sales order custom field;    -   Order CF Value Set Def 2918, in some embodiments definition for        a sales order custom field;    -   Order Ext CF Values 2919;    -   Order Line Search 2920, in some embodiments a search line for a        sales order;    -   Order Line 2921;    -   Order Shipment 2922, in some embodiments a shipment for a sales        order;    -   Order Line Product 2923, in some embodiments a product for a        sales order;    -   Order Credit Card 2924, in some embodiments a credit card for a        sales order; and    -   Order Shipment Line 2925, in some embodiments a shipment line        for a sales order.

FIG. 30 shows a database diagram 3000 including the transaction database228, and workflow database 3000 associated with the transactiondatabase. In some embodiments, the transaction database 228 and workflowdatabase 3000 are accessed by transaction processing servers 223 andmiddleware/web methods servers 224.

As described, supplier users can access the catalog via themiddleware/web methods servers 224, which then forward the supplieraccess request to the custom database servers 222 and processing modulesfor execution, in order, for example, to update their own supplier data.End users may be able to search multiple suppliers within the catalogvia the end user interface 212, subject to access rules set by the superuser. End users may search the catalog for specific end user productrequirements via the middleware/web methods servers 224, which forwardthe end user search request to custom database servers 222 andprocessing modules for execution. Subsequently, the end user may theninvoke requisition and purchase orders via the middleware/web methodsservers 224, which forward the end user order to the transactionprocessing servers 223 for execution.

In an embodiment, workflow database 3000 includes one or more of:

-   -   Workflow Step 3002;    -   Workflow Step Attr Value 3004, in some embodiments an attribute        value for a workflow step;    -   Workflow Process Definition 3006;    -   Workflow Activity Attr Value 3008, in some embodiments an        attribute value for a workflow activity;    -   Workflow Activity Relship 3010, in some embodiments an        relationship for a workflow activity;    -   Workflow Activity 3012;    -   Workflow Folder Selection Rule 3014, in some embodiments a        selection rule for a workflow folder;    -   Workflow Activity Instance 3016, in some embodiments an instance        of workflow activity;    -   Workflow Folder Membership 3018, in some embodiments membership        of a workflow folder;    -   Workflow Folder 3020;    -   Workflow Folder Activity Instance 3022, in some embodiments an        activity instance for a workflow folder;    -   Users 3024;    -   Workflow Folder Robot Relship 3026;    -   Workflow Folder Entry 3028;    -   Workflow Robot 3030;    -   Workflow Robot Attr Value 3032;    -   Workflow Dynamic Rule Group 3034, in some embodiments an dynamic        rule group associated with the workflow;    -   Workflow Dynamic Rule Group Audit Trail 3036, in some        embodiments an audit trail for a dynamic rule group associated        with the workflow;    -   Workflow Dynamic Rule 3038;    -   Workflow Dynamic Rule Element 3040, in some embodiments an        element of a dynamic rule associated with the workflow; and    -   Workflow Dynamic Rule Audit Trail 3042, in some embodiments an        audit trail for a dynamic rule associated with the workflow.

FIG. 31 shows a database diagram 3100 including the staging database3100, and staging catalog database 3101, associated with the stagingdatabase 3100.

In an embodiment, the staging catalog database 3101 includes one or moreof a staging items database 3102, a staging price database 3131, and asummary search database 3130.

In an embodiment, staging items database 3102 includes one or more of:

-   -   Item Attribute Attr Value 3103, in some embodiments a value for        an item attribute;    -   Item Attribute Valid Values 3104, in some embodiments a set of        valid values for an item attribute;    -   Item Attribute Audit Trail 3105, in some embodiments an audit        trail for an item attribute;    -   Item Attribute Definition 3106, in some embodiments a definition        for an item attribute;    -   Item Attribute Data 3107, in some embodiments data for an item        attribute;    -   Item 3108;    -   Chem Structure 3109, in some embodiments a description of a        chemical structure that may be ordered through the procurement        system;    -   Chem Structure Supplier 3110, in some embodiments a supplier of        a chemical structure;    -   Item Chemical 3111 in some embodiments a commercial item of a        chemical structure e.g., a container of a certain chemical        structure;    -   Supplier 3112;    -   Item Image Description 3113, in some embodiments a description        of an image or picture associated with an item;    -   Item Image File Data 3114, in some embodiments an image data        file (e.g., a JPEG image or GIF image, as commonly used in web        applications);    -   Item Inventory Config 3115, in some embodiments data for        configuring inventory of an item; and    -   Item Inventory Config Audi Trail 3116, in some embodiments a        list of changes to data or an audit trail for configuring        inventory of an item.

In an embodiment, staging price database 3131 includes one or more of:

-   -   Items 3132;    -   Supplier 3133;    -   Item Attribute Audit Trail 3134, in some embodiments a list of        changes to data or an audit trail for an item attribute;    -   Price Set Org Details 3135, in some embodiments details of a        price setting organization;    -   Price Set 3136, in some embodiments a set price;    -   Price Version Approval 3137, in some embodiments approval for a        price version;    -   Price Version 3138;    -   Price Set Version 3139;    -   Price 3140;    -   Submission Price Component 3141;    -   Price Version Loading Submission 3142;    -   Submission Audit Trail 3143, in some embodiments a list of        changes to data or an audit trail for a submission; and    -   Submission 3144.

In an embodiment, summary search database 3130 includes one or more of:

-   -   Supplier Price Date 3117, in some embodiments a data associated        with a supplier price;    -   Supplier Content Date 3118;    -   Organization 3119;    -   Supplier 3120;    -   Searchable Verticals by Rule 3121, in some embodiments        supporting rule-based searching;    -   Product Rule 3122, in some embodiments a rule related to a        product;    -   Product Vertical 3123, in some embodiments supporting        product-based searching;    -   Org Supplier Item Counts 3124, in some embodiments a count of        items stored at an organization supplier;    -   Product Category 3125, in some embodiments a category related to        a product;    -   Supplier Category Summary 3126, in some embodiments a summary of        a supplier category;    -   Item Incr Indexing Queue 3127, in some embodiments a queue for        incrementally indexing items;    -   Org Favorites Full Indexing Queue 3128, in some embodiments a        full-indexing queue for organizational favorites; and    -   Org Favorites Incr Indexing Queue 3129, in some embodiments an        incremental-indexing queue for organizational favorites.

FIG. 32 shows a database diagram 3200 including the transaction database228, PO database 2500, buyer invoice database 3300, seller invoicedatabase 3400, requisition database 2700, receipt database 2800, salesorder database 2900, workflow database 3000, and contracts database3200, associated with the transaction database 228.

In an embodiment, the contracts database 3200 includes one or more of:

-   -   Supplier 3201;    -   Form Configuration 3202;    -   Contract Type 3203;    -   Contract Form Relationship 3204, in some embodiments an        relationship between a contract and a form;    -   Contract Scheduler Relationship 3205, in some embodiments an        relationship between a contract and a scheduler;    -   Contract Owner Relationship 3206, in some embodiments an        relationship between a contract and an owner;    -   Contract Department Relationship 3207, in some embodiments an        relationship between a contract and a department;    -   Contract Fulfillment Center Relationship 3208, in some        embodiments an relationship between a contract and a fulfillment        center;    -   Contract Audi Trail 3209, in some embodiments a list of changes        to data or an audit trail for a contract;    -   Contract Tier Info 3210, in some embodiments tier information        for a contract;    -   Contract Budget Actual 3211, in some embodiments an actual        budget for a contract;    -   User 3212; and    -   Department 3213.

FIG. 33 shows a database diagram 3300 including the transaction database228, PO database 2500, buyer invoice database 3300, seller invoicedatabase 3400, requisition database 2700, receipt database 2800, salesorder database 2900, workflow database 3000, and contracts database3200, associated with the transaction database 228.

In an embodiment, the buyer invoice database 3300 includes one or moreof:

-   -   Invoice Configuration Section Title Help 3301, in some        embodiments help information for configuring an invoice section        title;    -   Invoice Configuration Section 3202, in some embodiments        configuration of a invoice section;    -   Invoice Configuration 3203;    -   Invoice Configuration Group Title Help 3304, in some embodiments        help information for configuring an invoice group title;    -   Invoice Configuration Group 3305, in some embodiments        configuration of an invoice group;    -   Invoice Configuration Element Validation 3306;    -   Invoice Configuration Element 3307, in some embodiments        configuration of an invoice element;    -   Invoice Configuration 3308;    -   Invoice Configuration Version 3309;    -   Active Invoice Configuration Version 3310;    -   User Selected Approver 3311;    -   Currency Exchange Rates 3312;    -   Invoice Audit Trail 3313, in some embodiments a list of changes        (audit trail) to an item attribute for auditing purposes;    -   Invoice Summary 3314;    -   Invoice 3315;    -   Workflow Activity History 3316;    -   Supplier 3317;    -   Invoice Line 3318;    -   Remit to Address 3319;    -   Pending Actions 3320, in some embodiments pending actions        relating to an invoice;    -   Contract 3321;    -   PO 3322, in some embodiments a purchase order;    -   PO Line 3323, in some embodiments a purchase order line;    -   Invoice Line Product 3324, some embodiments a product line        relating to an invoice;    -   Invoice CF Value Set Def 3325, in some embodiments to set the        definition of a custom field value in an invoice;    -   Invoice CF Value Set Ctxt 3326, in some embodiments to set the        context of a custom field value in an invoice; and    -   Invoice CF Value Set Value 3327, in some embodiments to set the        value of a custom field value in an invoice.

FIG. 34 shows a database diagram 3400 including the transaction database228, PO database 2500, buyer invoice database 3300, seller invoicedatabase 3400, requisition database 2700, receipt database 2800, salesorder database 2900, workflow database 3000, and contracts database3200, associated with the transaction database 228.

In an embodiment, the seller invoice database 3400 includes one or moreof:

-   -   Invoice Configuration Section Title Help 3401, in some        embodiments help information for configuring an invoice section        title;    -   Invoice Configuration Group Title Help 3402, in some embodiments        help information for configuring an invoice group title;    -   Invoice Configure Element Validation 3403;    -   Invoice Configuration Section 3404, in some embodiments        configuration of an invoice section;    -   Invoice Configuration Group 3405, in some embodiments        configuration of an invoice group;    -   Invoice Configuration Element 3406, in some embodiments        configuration of an invoice element;    -   Invoice Configuration 3407, in some embodiments configuration of        an invoice;    -   Invoice Configuration Version 3409, in some embodiments        configuration version of an invoice;    -   Active Invoice Configuration Version 3410, in some embodiments        configuration of an active invoice;    -   Supplier 3411;    -   Currency Exchange Rates 3412, in some embodiments currency        exchange rates associated with an invoice;    -   Invoice 3413;    -   User Default Remit To Address 3414, in some embodiments a        default remit-to address for a user associated with an invoice;    -   Invoice Line 3415;    -   Remit To Address 3416, in some embodiments a remit-to address        associated with an invoice;    -   Invoice Line Product 3417; and    -   User 3418.

FIG. 35 shows a database diagram 3500 including the end user database232, associated with the user/security database 3500. In an embodiment,the user/security database 3500 includes one or more of:

-   -   User Info 3501, in some embodiments information relating to a        user;    -   User Permission Index 3502, in some embodiments an index of        permissions relating to a user;    -   User Audit Trail 3503, in some embodiments a list of changes        (audit trail) for a user for auditing purposes;    -   Users 3504;    -   User Attribute Value 3505, in some embodiments the value of an        attribute associated with a user;    -   User Role Membership 3506, in some embodiments membership        associated with a user role;    -   Organization 3507;    -   Organization Attribute Value 3508, in some embodiments a value        of an attribute associated with an organization;    -   Department 3509;    -   Position Department Relationship 3510, in some embodiments a        relationship between a position and a department;    -   Position Department Role Relationship 3511, in some embodiments        a relationship between a position and a department role;    -   Position 3512;    -   Role Attribute Value 3513, in some embodiments the value of an        attribute associated with a role;    -   Role 3514; and    -   Role Audit Trail 3515, in some embodiments a list of changes        (audit trail) for a role for auditing purposes.

FIG. 36 shows a database diagram 3600 including the scheduler database3600. In an embodiment, the scheduler database 3600 includes one or moreof:

-   -   Job Input Data 3601, in some embodiments data relating to a job        input;    -   Job Description 3602, in some embodiments a description relating        to a job;    -   Job Execution Instance 3603, in some embodiments an execution        instance relating to a job;    -   Job Input 3604;    -   Job Output 3605;    -   Trigger 3606;    -   Filed Description 3607;    -   Job Output Data 3608, in some embodiments data relating to a job        output;    -   File Data 3609;    -   Instance 3610; and    -   Lock 3611.

FIG. 37 is a block diagram of a server system 3700. The system 3700comprises an electronic procurement (eProcurement) server 3720, locatedat an eProcurement provider 20 as previously described. The server 3720is coupled, either locally or remotely, to a database/storage 3760 thathosts a plurality of databases. These stored databases can include oneor more of a catalog database 2400, a staging database 3100, a buyer/enduser database 232, permissions 3734, a business rules database 3756,requirements 3732, quotas 3750, and other databases as described. Insome embodiments, the catalog database 2400 can correspond to a masterproduct database 236 as described earlier.

In some embodiments, the server 3720 can include one or more of a webserver 225, a middleware/methods server 224, a transaction processingserver 223, a custom database server 222, and an end user processingservers 221, as described earlier.

In some embodiments, the electronic procurement system includes aplurality of purchasing organizations, each having at least one user(e.g., users 3702, 3703, 3705) with permissions 3734 associated with theat least one user. In some embodiments, the permissions are determinedin accordance with business rules 3756. In some embodiments, thebusiness rules are associated with at least one of supplierrequirements, purchaser requirements, and governmental requirements3732. In some embodiments, the permissions are determined by asuper-user as described earlier, e.g., super-user 3704.

In some embodiments, the permissions 3734 associated with the user 3702determine the user's ability to purchase from the catalogs 2400associated with suppliers, and also to purchase non-catalog items. Thepermissions define a particular user's ability to purchase items basedon such criteria as the amount (e.g., dollar limit or number ofpurchases), type (e.g., lab/office supplies only orelectronic/consumer/personal items also), and priority of items (e.g.,speed of fulfillment) the user can purchase.

FIG. 37 shows a first user 3702, a second user 3703 and a third user3705, who access the server system through an internet connection, whichin one embodiment is a web connection 3755.

Business rules 3756 are associated with the plurality of users (users3702, 3703 and 3705). The business rules associated with each respectiveuser may be different. In some embodiments, these business rulesdetermine user permissions 3734 as described, workflow steps andoperations, order submission, order approval, and order payment, etc.

Catalog items from catalog database 2400, and also non-catalog items,are displayed to a respective user in accordance with the respectivebusiness rules associated with the respective user. If a business ruleprohibits a user from viewing a certain item, category, or supplier,then the respective item, category or supplier will not be displayed tothat user, even if other users with appropriate permissions may see it.

Throughout this application, “displaying” means at least that the serversends data for display to a client associated with the user. Prior todisplay, the data for display may be formatted by the server prior tosending to the client associated with the user, or may be formatted bythe client after receiving the data, or may include a combination ofthese operations.

A first item 3761, a second item 3762, and a third item 3764 aredisplayed to respective users 3702, 3703 and 3705 in accordance with thebusiness rules 3756 and permissions 3734. The users submit respectivepurchase requests 3766, 3768, and 3770 to purchase the respective items.

Following a purchase request, a purchase approval is determined 3714 (insome embodiments as an individual operation per item, or by group ofitems) for the catalog items displayed to the users and selected by theusers for purchasing. In some embodiments, the purchase approval can beperformed when a user submits a request to purchase the item (respectivepurchase requests 3766, 3768 and 3770), or later (e.g., when a purchaserequest is routed to an approving party for approval). The permissions3734 associated with a user may determine a purchasing amount that auser may purchase before approvals are required (e.g., purchase up to$25 without approval) as an individual transaction or an aggregatetransaction over time (e.g., $100 total purchases per month).

A purchase order is generated (in some embodiments, following a purchaseapproval) 3718, 3722, 3723 respectively for the purchase requisitions3766, 3768, 3770 respectively. Suppliers 3724, 3726, 3727 may beassociated with the purchase orders 3718, 3722, 3723 respectively.

The purchase orders may be combined into a large purchaser order ormaintained separately, according to business rules. As an example, ifthe users 3702, 3703, 3705 are at the same purchasing organization, andthe items for purchase all come from one supplier, then in someembodiments it would be appropriate to have one purchase order for allthree items ordered. In some embodiments, government and supplierrequirements 3732 determine if some items (e.g., special items such asradioactive materials, toxins, biohazards, select agents) must havetheir own separate purchase requisitions and/or purchase orders

In some embodiments, the purchases may be scheduled 3728, in accordancewith scheduling rules 3730.

In some embodiments, the business rules are specified by a super-user3704. The super-user 3704 may be a system administrator or manager at apurchasing organization associated with the users 3702, 3703, 3705. Thesuper user 3704 determines the permissions 3734 associated with theusers and the business rules 3756 applicable to the users and thepurchasing organization. In some embodiments, the business rules and/orpermissions include a procurement policy and purchasing permissions3763. The purchasing permissions may include definitions of purchasingapproval ability and purchasing limits for users. Purchasing approvalability determines which user can purchase or approve what type of item(e.g., only managers can purchase toxins or radioactive items). Purchaselimits determines who can approve a purchase and to what dollar amount(e.g., any purchase requisition over $25 needs management approval), asdescribed.

In some embodiments, the business rules 3756 may be customized accordingto at least one of a group consisting of by user (as described), byrole, and/or by department. For example, certain classes (job roles) ofusers (e.g., lab technicians) may have business rules associated withthat class, and different classes of users (e.g., senior scientist) mayhave different rules associated with their job role. In another example,users associated with a first department (e.g., engineering) may havedifferent permissions (e.g., ability to purchase engine parts)associated with them than users associated with a second department(e.g., accounting, having permission to purchase calculators.)

In some embodiments, the business rules 3756 and/or permissions 3734 mayhave an option to prevent approval by a user of his or her own purchaserequest, in accordance with the business rules. This option may beenabled by user, by role, and/or by department, as described. Thisoption may reduce inappropriate use (e.g., unauthorized personalpurchases) of the electronic procurement system 20. In this case, if auser submits a purchase request for an item, the purchase request isrouted for approval by a person other than the user (in someembodiments, more senior than the user), even though the user mayotherwise have sufficient purchasing ability (within the user'spurchasing limit) to purchase the item without approval.

In some embodiments, business rules 3756 and/or permissions 3734 mayhave an option to prevent approval by a user of his or her own purchaserequest over a spending limit, in accordance with the business rules. Asdescribed, a user may have permission to purchase up to a certain amount(as described) without requiring approval, as determined by businessrules and permissions.

In some embodiments, the business rules are stored at the server 3720.In some embodiments, the purchase requisitions (3766, 3768, 3770) andpurchase orders (3718, 3722, 3723) are stored at the server.

In some embodiments, the supplier (e.g., 3724, 3726, 3727) to which apurchase order is assigned is determined according to a procurementpolicy and with contractual agreements. For example, a purchasingorganization may obtain a quantity discount if a quota 3750 of units ispurchased from a particular supplier. In this instance, purchase ordersmay be preferentially assigned to that supplier to meet the quota andobtain the discount. Similarly, contracts may require that certain typesof items be ordered from contracting suppliers. In some embodiments,items may be preferentially displayed to users based on quotas ofpurchases to be filled. In some embodiments, generating a purchase orderincludes associating workflow rules with the purchase order, inaccordance with business rules.

In some embodiments, items (catalog and non-catalog) are displayed to auser in accordance with the respective business rules 3756 associatedwith the respective items. In some embodiments, items (catalog andnon-catalog) are displayed to a user in accordance with the respectivebusiness rules associated with the supplier.

FIG. 38 is a block diagram of a server system 3800. The server system3800 includes users (3702, 3703, 3705), items (3761, 3762, 3764),purchase requests (3766, 3768, 3770), purchase approval 3714, purchaseorders (3718, 3722, 3723), suppliers 3724, 3726, 3727, and purchasescheduling 3728, as described.

FIG. 38 illustrates a schematic of an exemplary graphical dashboard 3830displaying status for the purchase requisition, purchase approvals, andpurchase orders as described. A purchase request made status 3810 showswhether a purchase request has been submitted for a user or item. Apurchase approved status 3812 shows if a purchase request for the userhas been approved. A purchase order generated status 3814 shows if apurchase order associated with the user has been generated. In someembodiments, the status information is determined by checking one ormore of the Purchase Order Database 2500, the Purchase Order WorkflowActivity History 2510, Purchase Order User Selected Approver 2536, andPurchase Order Pending Actions 2538. A purchase scheduled status 3816shows if a purchase associated with the user has been scheduled. Apurchase fulfilled status 3818 shows if a purchase associated with theuser has been fulfilled. An invoice paid status 3820 shows if an invoiceassociated with the user's purchase has been paid.

In some embodiments, these statuses may be associated with a user, anitem, or a supplier. The status are displayed on the graphical dashboard3830 (in some embodiments generated at the server 3720 but displayed ata user's client), including on a sales order queue 5300, a graphicaldisplay of sales orders status, which is described below in FIG. 53. Thedisplaying includes presenting on the graphical dashboard approval,purchasing and fulfillment status for the item. In some embodiments, thegraphical dashboard is dynamically generated at the server 3720 inaccordance with business rules 3756 stored at the server, as described.

FIG. 39 illustrates an exemplary new/non-catalog item creation tool inaccordance with the present invention. The tool 3900, 3901 may be usedby users with appropriate privileges (as may be enforced by manageprivileges 1536; FIG. 15, 1536-A; FIG. 16, 1660, 1664) to describe andconfigure the new item that is to be added/stored to the master productdatabase 236 and, more specifically, may be stored in, for example, theitems database 2401 of the catalog database 2400; each of thesedatabases is accessible to all users with appropriate privileges withinthe same organization, as well as potentially by all users withappropriate privileges within an organization different from the one towhich the user who added the new item belongs (users may search for thenew item via at least the search engine 22, and in accordance withbusiness rules (e.g., based on cost, product type, or supplier; FIGS.8A-8D)). In some embodiments, the new item may be stored in a databaselocal to the user who added the item. Before the new item is stored in adatabase, a check is made to determine whether the new item is alreadystored in a database. If the new item is already stored in a database,then the user is notified via the tool 3900, 3901 by an appropriatemessage. The user may then reinitiate the process of adding the new itemwith a different configuration, or disregarding that new item as italready exists in a database. The tool 3901 may include, for example, afield for: describing the new item 3902, entering a catalog number toassign to the new item 3903, entering or choosing a product size 3904,entering a quantity for requisitioning/ordering 3905, entering a priceestimate 3906, entering a currency type (e.g., USD, EURO, YEN, etc.) forthe price estimate 3907, and entering or choosing a packaging type(e.g., EA) 3908. The user may then choose to invoke a save and closefeature 3909, a save and add another feature 3910, or a close feature3911. The action of saving (3909 or 3910) transfers the entered fielddata to the master product database 236 and, more specifically, forexample, the items database 2401 of the catalog database 2400. Theaction of closing (3911) would not save the entered field data. Inanother exemplary embodiment, the tool 3901 may further include, forexample, a field for: a brand, a delivery date or time, a reorder flag,supplier data, or shipping data. The user configuring the options forthe new item may choose to view and associate product details 3912 withthe new item. In addition, the user may or may not choose to associate asupplier with the new item 3913 3903. If the user chooses to associate asupplier with the new item, the user may associate either an existing ornew supplier (FIG. 17; data on existing suppliers is stored in thesupplier database 1775); the user may also be presented with analternative supplier to the one chosen by the user to associate with thenew item. If the user does not associate a supplier with the new item,then a user with appropriate privileges (e.g., approver-level user,super user, or other similar user) in the organization will be taskedand queried by the system to associate a supplier with the new itemduring the workflow process as the new item proceeds to an approver, orbefore that time, in accordance with business rules. A user may create anew item and quickly add another new item for the same supplier withouthaving to search for the same supplier again, once a supplier has beenassociated with a new item. Also, a user may choose to not enter acatalog number 3903 (e.g., SKU) and force a search on the master productdatabase 236 (the search may, for example, be run on the catalogdatabase 2400). Further, a new item that is searched for and added to acart by a user with appropriate privileges, via the search engine 22 andcart and requisition tool 1100, respectively, is flagged as a new itemfor the purpose of routing the new item appropriately, via the workflowmanagement engine 1680 (FIG. 16), during the workflow process of apurchase requisition/order to an appropriate approver and beyond inaccordance with business rules. If the item is approved for purchasingand a sales order is sent to the appropriate supplier(s), then similarrouting patterns are followed for a workflow related to routing thesales invoice with the new item back to the appropriate user. At thattime, the user may pay the amount due on the invoice via, for example,the order/payment engine 1690 (FIG. 16) for the new item and other itemsthat may also appear on the invoice. The appropriate supplier may thenreceive the payment via, for example, the receive payment engine 1780(FIG. 17), and may then initiate the process of fulfilling the ordervia, for example, the sale fulfillment engine 1770 and accordinglypackaging the new item(s) (based on the preferences specified inpackaging 3908) and shipping the item(s) 1772.

In FIG. 39, the user 3702 requests access to a first item 3902. Thefirst item 3902 may be a catalog or non catalog item associated with theelectronic procurement system. If the first item is unavailable 3904, asecond available item 3906 corresponding to the first item 3902 isidentified. The second item could be a similar item as identified in thecatalog 2400, or could be a non-catalog item. An available item is onethat is in stock at a supplier or at an internal stockroom, and may beordered for prompt delivery. An unavailable item includes one that isout of stock, back-ordered, discontinued, or one that cannot otherwisebe delivered promptly via the electronic procurement system.

The second available item 3906 is displayed to the user in accordancewith business rules 3756 associated with the user. In some embodiments,the business rules are associated with the item. In some embodiments,the business rules are associated with a supplier of the item.

The user submits a purchase request 3766 for the second available item3906, and a purchase approval 3714 is determined. A purchase order 3718is generated for the item. The purchase order may be associated with asupplier 3724. The purchase request may be scheduled 3728, all asdescribed.

FIG. 40 shows a block diagram of an e-procurement process flow operatingon a server system 4000. Server system 4000 also includes server 3720and databases as described. The databases include catalog database 2400,permissions 3734, a business rules database 3756, requirements 3732,scheduling rules 3730, and other databases as described.

FIG. 40 illustrates an exemplary form layout configuration tool inaccordance with the present invention. The tool 4000 and its formsconfiguration feature 4001 may be used to design and/or configure thelayout 4002 and elements 4003-4008 of a new or existing form. The formsconfiguration feature 4001 may also be used to build a new form byinvoking the build new form feature 4009. Once an existing form isconfigured or a new form is created, the preview form feature 4010 maybe invoked to view how the form is currently configured. Moreover, allof the existing forms (e.g., a form library) associated with the user orthe user organization may be displayed in the tree-like frame 4011 forthe user to choose from for further editing or configuration. Theexisting forms may be displayed in accordance with user privileges,organization privileges, or business rules, such that only theappropriate forms are displayed in the frame 4011. Moreover, layoutdetails may be configured via the layout details tool 4002. The layoutdetails tool 4002 may include, for example, the following elements forconfiguration and layout on a new or existing form: instructions 4003,supplier information 4004, order information 4005, personal information4006, sample 4007, or field views 4008. Order information 4005 mayinclude, for example, item, item information, service, serviceinformation, quantity 4016, price, currency, order date, delivery date,shipping date, priority, menu, privilege level, order size 4017, ororder type 4018. Similarly, order information 4005 may further include,for example, a title and help text section 4015 to accompany the new orexisting form. Also, field views 4008 may include, for example,unassigned form fields 4012, user defined form fields 4013, or allfields 4014. Unassigned form fields 4012 may include, for example, theelements: capital expense, catalog number, commodity code, contract,external attachments, form type, health and safety, internalattachments, manufacturer name, manufacturer part number, packaging,product description, product size, taxable, or UN/SPSC. Similarly, userdefined form fields 4013 may include, for example, the elements: textbox, numeric text box, unit price, check box, dropdown list, tab, frame,tree, multimedia component, scroll menu, check box, text area, radiobutton group, date, HTML area, link, image, or item list. Further, allfields 4014 may include, for example, the elements of unassigned formfields 4012 and user defined form fields 4013. All of these elements maybe customized for placement on a new or existing form in accordance withthe user's preferences; moreover, the elements may be pre-defined.

A user may first request to create a custom form for ordering an item(s)or searching for an item(s) via the build a new form feature 4009. Onlyusers with appropriate privileges will be permitted to create a customform; the user privileges may be enforced by manage privileges 1536. Ineither case, the appropriate database will be accessed and the form willeither be stored there, in the case of a new form, or a search query mayrun on the database based on the form, and search results returned tothe user. When a new form is created (or, an existing form is edited) atleast the forms database 2300 may be accessed; the master database 236and, more specifically, for example, the catalog database 2400 may alsobe accessed, including the items database 2401 or the prices database2430. Once invoked, the build a new form feature 4009 may present theuser with the layout details tool 4002 for customizing and configuringthe new form per the user's preferences (or, the organizations'preferences as well). For example, the user may choose to provideinstructions 4003 along with the form, in order to guide a user usingthe form on how to place orders using the form or, similarly, how toinvoke searches also using the form. In addition, a user may alsoprovide supplier information 4004 to accompany the form like, forexample, a supplier: name, address, telephone number, orderingpreferences, payment preferences, shipping preferences, or contractualpreferences. Furthermore, a user may also provide order information 4005to accompany the form like, for example, an order: quantity 4016, size4017, or type 4018. A user may also provide personal information 4006 toaccompany a form like, for example, name, title, department, address,telephone number, email, payment preferences, delivery preferences, orcontractual preferences. Moreover, a user may also provide a sample ofan item associated with the form via the sample 4007 element. All of theelements 4003-4008 of layout details 4002, or other elements notnecessarily shown in this exemplary embodiment, may be customized forplacement on the new or existing form in accordance with a user'spreference.

A determination is made (4013) whether there is sufficient stock of theitem available to fulfill both user purchase requests. If there isinsufficient stock of the item available to fulfill both purchaserequests, the user purchase requests are prioritized (4014). If there issufficient stock, then purchase orders may be generated (4018) withoutprioritizing. Prioritizing (4014) can include determining which userrequest (if any) is highest priority, as described. In some embodiments,user requests of a similar priority level are filled according to afirst in, first out (FIFO) method. In some embodiments, one or both ofthe user purchase requests are placed in a queue (4016) according to theprioritizing. One or more purchase orders 4019, 4020 are generated(4018).

In some embodiments, prioritizing the user purchase requests isperformed in accordance with the importance of a respective project ortask associated with each respective user. In some embodiments,importance may include factors such as remaining schedule, amount ofbudget, including budget overruns, proximity to deadlines or milestones,and other business or project management factors.

In some embodiments, user purchase requests of a similar priority levelin the queue are fulfilled according to a first in, first out (FIFO)method. In some embodiments, the order of insertion of a purchaserequest into the queue is determined by prioritizing 4014. In this case,the prioritizing may include sorting purchase orders into prioritygroups, which are then inserted into the FIFO in order of prioritygroup. A highest priority group is placed in the FIFO first, a nexthighest priority group goes next into the FIFO, and finally a lowestpriority group goes into the FIFO last.

In some embodiments, a user having an order in the queue 4016 isnotified 4021 when the ordered item is ready for fulfillment 4020. Insome embodiments, this occurs when the item 4006 is delivered bysupplier 3724.

In some embodiments, an alternative available item 3906 (as described)is presented (4023) to a user 4004 having an order in the queue, inaccordance with a predicted fulfillment delay. For example, if a userhas already placed an order, and the electronic procurement systemdetermines that the already-placed order will be delayed, an alternativeitem may be presented to the user as described in reference to theprocess flow 3900. The alternative item may be presented as an item tobe ordered from an external supplier or an item from an internalstockroom. In some embodiments, where the original (unavailable) item4006 was already approved for purchase, the alternative item 3906 maynot require submission of a purchase request, approval, etc. since it isa substitute for the originally approved item.

In some embodiments, the prioritizing is performed according to feesassociated with the respective users. In some embodiments, a purchasingorganization (buyer) may choose to subscribe or pay for a higher leverof service, including receiving preferential ordering position for ashort-supply or allocated product. Tiers of service may be implementedin the electronic procurement system, where lower tier (lower paying orfree) users of the system receive lower priority service that premium(higher fee paying) users. In some embodiments, if an item is in shortsupply, the purchasing process may become a bidding or auction process,whereupon users submit orders as bids.

In some embodiments, prioritizing (4022) may be performed uponfulfillment of the item order (4020), in addition to or instead of atthe time of order. Upon fulfillment (delivery of the item), adetermination may be made whether there is sufficient stock of the itemavailable to fulfill both user purchase requests 4010 and 4012. Theprioritized requests may be placed (4024) in a fulfillment FIFO orqueue. The prioritized requests may be fulfilled according to thepriority.

In some embodiments, if at time of delivery an alternative itemcomparable with the requested item is available, and the requested itemis not available in sufficient stock to satisfy both the first userrequest 4010 and second user request 4012, one or more of the userpurchase requests may be fulfilled with the alternative item. Forexample, if a first user A and second user B each order one ten-pack ofnotepads, the delivery fulfillment might include just one ten-pack andone twelve-pack. In this delivery, the twelve-pack is an alternativeitem comparable with the requested item ten-pack (as it can provide atleast ten notepads, even if there are two left over), so the twelve packcan be used to fulfill the purchase request for a ten pack, as asubstitute.

FIG. 40A illustrates an exemplary form general configuration tool inaccordance with the present invention. The tool 4000A and its formgeneral configuration feature 4001A may be used to configure the generalfeatures of a new or existing form. The feature 4001A may display aversion date/time or a created by field. The user may input a versiondescription 4004A, or, if one is already available, then it wouldalready be displayed. The tool 4001A may also include a configurationparameters feature 4002A, which may further include, for example, theelements: form title 4005A, form type 4006A, limit supplier selectionoption 4007A, selected suppliers feature 4008A, currency 4009A, or fixeddistribution 4010A, or supplier name 4003A. The selected suppliersfeature 4008A allows the addition of suppliers to associate (or, add)with the new or existing form. Once added, the supplier(s) name andother relevant information, like, for example, address or telephonenumber are shown; a user may choose to only associate a limited set ofsuppliers. Similarly, a selected contracts feature (not shown) may alsoallow the addition of a contract(s) to associate (or, add) with the newor existing form. In parallel, with the contract management feature(discussed below), an appropriate contract may either be created or anexisting contract may be updated accordingly (e.g., tiers may beenforced, or special pricing may be available, etc.); this may be donevia the contact management engine 1688, 1784 and contracts database3200. Then, the configured form that has been edited or created by theuser may, for example, be stored in the forms database 2300 and may, forexample, be managed by form management 1693, 1783, or 1943, accordingly.

FIG. 41 illustrates an exemplary data structure 4100 for an inventory ofan item. In some embodiments, this data structure is stored in the itemdatabase 2410, in the master database 236, at the eProcurement server20. In some embodiments, the inventory data structure could be stored ata purchaser server, or at a purchaser client. The data structure mayinclude purchase prices 4012, purchase quantities 4104, dates ofpurchase 4106, average cost of items per purchase 4108, shelf age ofeach purchase 4110, markup to be added to each purchase 4112, sale price4114, and inventory 4116 of the item. An exemplary history of purchases(4118, 4120, 4122, 4124) is shown also. An exemplary sale history mayalso be included in the data structure.

In some embodiments, by analyzing a series of user purchases of an item(e.g. history 4118, 4120, 4122, 4124), a property (such as cost, time ininventory, spoilage status, etc.) per item purchased is determined.Inventory 4116 is managed (by the server, or by a user accessing theserver) based on the property per item. The managing includes makingdecisions to purchase items to replenish inventory, to deplete inventoryin order to sell items by a ‘best before’ date, determining pricing toachieve a desired markup, etc. In some embodiments, the property peritem is a cost per item purchased (e.g. average cost 4108). The averagecost may be calculated by dividing the purchase price 4102 (total) bythe quantity purchased 4104.

In some embodiments, the cost per item includes a holding cost per unitof that item. This holding cost can include depreciation, valuereduction due to obsolescence, shrinkage, reduction of remaining shelflife, etc. In some embodiments, managing includes determining a saleprice per item 4114, based on the cost per item 4108 and a markup 4112.In some embodiments, the managing is performed by a user at thepurchaser using manage purchases engine 1533. The sale price may also bereduced in accordance with shelf age 4110. The shelf age may becalculated by subtracting the date purchased from the current date tofind the number of days since purchase of that batch of items. The saleprice 4114 may be calculated by multiplying the average cost per item4108 by the markup 4112.

In some embodiments, the property per item is a spoilage status, basedupon an average holding time per item. This is used for food, medicines,and organics that have ‘best before’ date. In some embodiments, theproperty per item is velocity of purchases and/or velocity of sales forthat item. In some embodiments, the property per item is a predictedout-of-stock time based upon the velocity of purchases and a velocity ofsales.

The categories and values described here are exemplary, and otherproperties and calculations could be used to achieve the result ofmanaging inventory.

FIG. 42 shows a block diagram of a process flow, implemented at a serversystem 4200. The process flow shows an e-procurement process foridentifying a discrepancy between a purchase document and an invoice.

Server system 4200 also includes server 3720 and databases as described.The databases include catalog database 2400, permissions 3734, abusiness rules database 3756, requirements 3732, scheduling rules 3730,and other databases as described.

A supplier invoice 4210 is received by the electronic procurementsystem. In response to the receiving, a purchase document correspondingto the invoice is identified (4230). Purchase documents may include oneor more of a purchase request 4212 and a purchase order 4214. Thecontent of the purchase document is compared (4216) to the supplierinvoice 4210. A discrepancy is identified (4217) between the purchasedocument and the invoice. A notification is generated based upon theidentified discrepancy, and may be sent to a user associated with thepurchase order 4212 or request 4214. The notification can include anonline dispute notification 4222, a request for payment approval 4224,or a notification of automatic payment (4226).

The discrepancy check 4217 compares properties such as price, quantity,and delivery date 4220 between the purchase documents and the invoice.In some embodiments, identifying a discrepancy includes determining if aproperty associated with the invoice is outside of a tolerance range4218. The tolerance range may be specified by business rules 3756. Ifthe discrepancy between the purchase document and the invoice is above athreshold (e.g. percentage mismatch, dollar value, number of days late,number of defects, etc.), then the dispute notification 4222 is sent tothe supplier, and in some embodiments to a user associated with thepurchase request and purchase order. In some embodiments, the supplierand a purchaser associated with the invoice may access an online disputeresolution mechanism 4222, which may be hosted at the electronicprocurement system. If the discrepancy is minor, the invoice can be sentto the user with a request for payment approval 4224, i.e. a request toverify that the match is correct. If there is no discrepancy, then theinvoice is sent for automatic payment 4226.

The discrepancy check 4217 can include performing at least a two waymatch between the invoice and the purchase document. A two way match iswhere one of the purchase request 4212 and purchase order 4214 arematched with the invoice 4210. In some embodiments, the discrepancycheck 4217 can include performing a three way match, including:comparing both the purchase request 4212 and the purchase order 4214 tothe invoice 4210. In some embodiments, delivery documents may becompared with the purchase documents and the invoice.

In some embodiments, identifying a discrepancy (4216) includesdetermining if an alternative item comparable with the requested itemhas been delivered. If the purchase order or request has been satisfiedby the alternative item, then the purchase request or purchase order maybe treated as satisfied and the invoice paid by the user. For example,if a twelve pack of notepads is delivered instead of a ten pack, asdescribed.

FIG. 43 is an exemplary screenshot 4300 of a workflow configuration userinterface, generated by workflow management engine 1680. A super user oradministrator uses this interface to configure steps and operationsassociated with a workflow. This configuration is typically performed atthe super user's client, and the configuration data is saved at theeProcurement system 20.

Window 4310 shows status items for a particular step in the workflow.Save option 4330 allows changes to the workflow to be saved. Steps 4320shows steps in the workflow associated with a purchase or operation.Import button 4340 allows workflow steps to be imported. Export button4345 allows workflow steps to be exported. These workflow steps arestored in the workflow database 3000, in at least workflow step 3002.

FIG. 44 is an exemplary screenshot 4400 of an advanced dynamic workflowsetup rule group menu, generated by workflow management engine 1680.This interface is used by a super user or administrator to setup rulegroups, and changes are stored at the eProcurement system 20, asdescribed. Changes are made to the workflow dynamic rule group 3034, andworkflow dynamic rule group audit trail 3036, both stored in workflowdatabase 3000.

In this menu, groups are used for easy reference and organization ofindividual rules. Groups are referenced within the workflowconfiguration. The menu includes workflow tabs 4410 to navigate throughthe workflow options. A create new rule group button 4415 allowscreation of new workflow rules. A rule group list 4420 shows createdrules. An edit selected rule group menu 4430 allows a user to selectindividual rule groups for editing. A pair of save and delete buttons4435 allow changed rules to be saved or rules to be deleted.

The rule management operations described (as follows) in FIGS. 45, 46,47 may be performed using one or more of the Workflow Folder SelectionRule 3014, Workflow Dynamic Rule Group 3034, Workflow Dynamic Rule GroupAudit Trail 3036, Workflow Dynamic Rule 3038, Workflow Dynamic RuleElement 3040, and Workflow Dynamic Rule Audit Trail 3042, in workflowdatabase 3000, shown in FIG. 30. Product rule management may beperformed using Product Rule 3122, from summary search database 3130,shown in FIG. 31. The menus described in FIGS. 45, 46, 47 are accessedby a super user or administrator when configuring the workflow rules,and changes are stored at the eProcurement system 20, as described. Themenus described are generated by the workflow management engine 1680,residing on the eProcurement system 20.

FIG. 45 illustrates an exemplary user-defined searchable attributes itemassignment interface in accordance with the present invention. Theuser-defined search attributes item assignment interface tool 4500 andits corresponding item assignment feature 4501 may be used to assign (orassociate) 4502 a searchable field or attribute to a specific item(s)(or, in an alternative embodiment, a user, organization, supplier, orpurchase/sale). That is, once assigned (4503, 4504) and provided withone or more values, the searchable field or attribute may be used by thesearch engine 22 to search the appropriate database(s) (or, databaseindex) (described above) for more efficiently retrieving the specificitem(s) (or, in an alternative embodiment, a user, organization,supplier, or purchase/sale) according to the searchable field orattribute.

The rules management setup menu includes workflow tabs 4510 to navigatethrough the workflow options. A rule information menu 4515 showsinformation regarding a particular rule. An approver menu 4517 showsapprovers for a rule and allows approvers to be added and removed. Adocument level rules menu 4520 allows rules to be specified perdocument, via a drop down menu 4525. A line level rules menu 4530 allowsrules to be specified per line item, via a drop down item 4535.

FIG. 46 is an exemplary screenshot 4600 of an assign rule to group menu.In this menu, multiple rules can be assigned to a single group by theuser or super user. This offers flexibility in being able toadd/modify/delete rules to workflow without having to change theworkflow configuration since the configuration references a Rule Groupand not the rules themselves.

The assign rule to group menu includes workflow tabs 4610 to navigatethrough the workflow options. An add rule button 4615 allows a new ruleto be added. A rules menu 4617 shows rules assigned with a particulargroup. The rules menu includes a rule group field 4620, a rule namefield 4622, a rule description field 4624, and a select field 4626. Dropdown menus 4630 and 4632 allow actions to be selected for a rule orrules.

FIG. 47 is an exemplary screenshot 4700 of an import/export rules groupmenu. In this menu, individual rules and groups of rules can be importedor exported by a super user or administrator to facilitate integrationwith other systems. Additionally, groups and rules can be ported viaelectronic file between application environments, such as from test toproduction environments. In some embodiments, the groups and rules areported as an XML based file.

The import/export rules group menu includes workflow tabs 4710 tonavigate through the workflow options. A request menu 4715 allows importor export actions to be initiated. An action drop down menu 4720 allowsa user to select a desired action. A recent activity window 4730 showsrecent import/export requests submitted. Import instructions 4725 assista user in importing rules.

FIG. 48 is an exemplary screenshot 4800 of an item setup menu within asupplies manager application. This menu allows key attributes of an itemto be managed and pricing for fixed pricing items to be managed. Thismenu is generated at the eProcurement server 20, in some embodiments bythe catalog management engine 1695 and/or the catalog module 2120. Themenu is accessed by a user (or super user) at the supplier when settingattributes and pricing for items. Attributes and prices for items, setusing the item setup menu, are stored at the catalog database 2400,under items data base 2401 (for individual item attributes) and pricedatabase 2430 (for prices associated with items).

The item setup menu includes workflow tabs 4810 to navigate through thesupplies manager options. The attribute value menu 4820 includes thefollowing fields:

Part number 4822, a part number for the product;

Product Description 4824;

Packaging UOM 4826, unit of measure for packaging;

Product Size 4828

Product Color 4830;

Status 4832, the status relating to a product (e.g., available,unavailable, backordered, etc);

UNSPSC 4834, the United Nations Standard Products and Services Code,where UNSPSC is a coding system to classify both products and servicesfor use throughout the global eCommerce marketplace;

Category 4836, for product category;

Searchable Keywords 4838, keywords or tags best describing the productthat are used as hits for a user search;

Manufacturer Name 4840;

Manufacturer Part Number 4842;

Long description 4744, a detailed description of the product;

Lead Time 4846, expected time between ordering and receiving the item;

UPC 4848, the universal product code (barcode) for the product;

More Information URL 4852, URL link to more information about the item;

Image URL 4854, product image URL;

MSDS URL 4856, material safety data sheet URL;

Technical Data Sheet URL 4858, a URL link to a datasheet for the item;

Is Recycled? 4862;

Is Controlled Substance? 4860, a flag indicating a potential controlledsubstance such as certain drugs, opiates, etc.;

Is Hazardous Material 4864, a flag indicating a potential hazardous(e.g., biohazard, fumes, etc) item;

Is Radioactive? 4866, a flag indicating a potential restrictedradioactive item;

Is Minor Radioactive? 4868, a flag indicating a potential restrictedradioactive item;

Is Toxin? 4872 a flag indicating a potential toxic substance such aspoison;

Is Select Agent? 4870 a flag indicating select agents, which arepathogens or biological toxins that have been declared by the U.S.Department of Health and Human Services or by the U.S. Department ofAgriculture to have the “potential to pose a severe threat to publichealth and safety”; and

Upload new image field and button 4874.

A create new item button 4880 and copy standard data to new button 4882are also present.

FIG. 49A is an exemplary screenshot 4900 of a setup inventory attributesmenu. In this menu, inventory parameters are inherited from thefulfillment center where the item is stocked. The parameters can beoverridden at the item level as necessary. The parameters drivereplenishment functionality. This menu is generated at the eProcurementserver 20, in some embodiments by the catalog management engine 1695and/or the catalog module 2120. For non-catalog items, it may begenerated using a purchasing engine 1681. The menu is accessed by a user(or super user) at the supplier when setting attributes for inventory.These inventory attributes are stored at the catalog database 2400,under item inventory config 2526, and changes are stored in iteminventory config audit trail 2428.

The setup inventory attributes menu includes workflow tabs 4910 tonavigate through the workflow options. A fulfillment address menu 4920shows an address for a supplier. An inventory parameter menu with tabs4930 allows navigation through the inventory options.

The inventory parameter menu 4930 includes the following fields:

Minimum inventory level 4932;

Maximum inventory level 4934;

Reorder point 4936; and

Economic Order Quantity 4938.

A select box menu to override default values 4940 is also present.

In some embodiments, the item attribute/parameter management may beperformed using the items database 2401, including Item Inventory Config2426 for configuring inventory of an item, and Item Inventory ConfigAudit Trail 2428 for tracking changes in inventory configuration.

FIG. 49B is an exemplary screenshot 4950 of an item setup pricing menu.In this menu, a pricing model is inherited from the fulfillment centerdefault pricing model. The pricing model can be overridden at the itemlevel. In some embodiments, the pricing models may include fixed (priceis constant), FIFO (First in first out—price is based on cost of itemsplus a markup using a FIFO model, e.g., the price for an item is theprice of the oldest one in inventory plus a markup), and cost averagingwhere the price of an item is based on the average cost of all of theitem in inventory plus a markup.

In some embodiments, the item pricing management may be performed by auser (or super user) using the price database 2430, including Price Set2440 (a price for the item), Price Version Approval 2442, and PriceVersion 2444 (a version of a price associated with the item). This menuis generated at the server 20, in some embodiments by the catalogmanagement engine 1695 and/or the catalog module 2120. For non-catalogitems, it can be generated using a database management module 2170. Themenu is accessed by a user (or super user) at the supplier when settingattributes and pricing for items. Attributes and prices for items, setusing the item setup menu, are stored at the catalog database 2400,under items data base 2401 (for individual item attributes) and pricedatabase 2430 (for prices associated with items).

The item setup pricing menu includes menu tab 4955 to navigate throughthe pricing options. The setup pricing menu 4950 includes a pricingmodel 4960 with drop down menu 4964 to select the pricing style and amarkup percentage 4963. A select box menu to override default values4966 and a save button 4968 are also present.

FIG. 49C is an exemplary screenshot 4970 of an item setup replenishmentlink menu. In this menu, an item managed in inventory can be linked toone or more e-commerce items or non-catalog items for replenishment. Adefault item can be configured for use in the replenishment report. Thismenu is generated at the server 20, in some embodiments by thepurchasing engine 1681. The menu is accessed by a user (or super user)at the supplier when maintaining an item in inventory.

In some embodiments, the item replenishment management may be performedusing the receipt database 2800. This database includes a Receipt LineInventory Replenishment field 2818, which may correspond to an inventoryreplenishment line for a receipt.

The item setup replenishment link menu includes menu tab 4980 tonavigate through the replenishment options. The setup replenishment linkmenu 4980 includes a set preferred supplier button 4982, a supplierfield 4984, an item name field 4986, a catalog number field 4988, a sizefield 4990, a unit of measure field (UOM) 4992, a stocked units field4994, and a price field 4996. Selecting any of these buttons updates theitems database 2401 and/or the price database 2430.

FIG. 50 is an exemplary screenshot 5000 of a supplier setup inventoryparameters menu. This menu is generated at the eProcurement server 20,in some embodiments by the sales management engine 1760. The menu isaccessed by a user (or super user) at the supplier responsible forsetting parameters for sales inventory.

In this menu, inventory parameter defaults can be set for all itemsstocked within the fulfillment center. The quantity on hand or in/out ofstock displayed in search results is configured. Default parameters forfulfillment for all sales orders managed at this fulfillment center areconfigured. Default parameters for pricing models for items stocked inthe fulfillment center are configured. A location hierarchy isconfigured, e.g., shelves, bins, etc. Kiosk (self-checkout) parametersare configured.

The supplier setup inventory parameters menu includes menu tabs 5010 and5020 to navigate through the inventory options. A supplier label 5005shows an internal stockroom as the supplier. A kiosk tab 5040 showsoptions associated with a self-checkout option. A price tolerance selectbox 5050 allows selection of a price tolerance. An auto-allocatebackordered items box 5060 allows back ordered items to be allocated.

FIG. 51 is an exemplary screenshot 5100 of a search results menu. Thismenu is generated at the eProcurement server 20, in some embodiments bythe purchasing engine 1681 and/or catalog engine 1655. The menu isaccessed by a user at the purchaser when ordering items and monitoringstock of items. In this menu, both internally stocked (stockroom) andexternal vendor products are searched upon and shown in results. Themenu displays whether an item is in/out of stock for internally stockeditems in the stockroom, and actual quantity on hand can be seen.

Supplier name and/or an icon 5110 may be used to indicate that aninternal stockroom holds the searched items (staplers). Add to activecart option in drop down menu 5112 allows a user to select items to beadded to a shopping cart.

FIG. 52 is an exemplary screenshot 5200 of a shopping cart menu. Themenu is generated at eProcurement server 20, and is accessed by a userat the purchaser when ordering items, e.g., an individual user withpurchasing permissions or a purchasing department. In this menu, bothinternally stocked/fulfilled and external vendor products are orderedusing the same interface. Stocked and external vendor products can bepart of the same requisition.

An add non-catalog item button 5205 allows non-catalog items to be addedto the cart. A first line item 5210 shows a product description 5215from an external supplier. A supplier information window 5230 showscontract, purchaser order, and quote details for the external supplier.A second line item 5220 shows a product description 5225 from anexternal supplier. A drop down menu 5235 allows actions (e.g., add tofavorites) for selected suppliers.

FIG. 53 is an exemplary screenshot 5300 of a sales order queue. In thismenu, sales orders are routed to the appropriate departments, users, andqueues depending on organization-specific rules. This menu is generatedat the eProcurement system 20 using a rules based sales engine 1760, insome embodiments similar to engines used for other documents, e.g.,requisitions and purchase orders using purchasing engine 1681. The salesorder queue is accessed by a user at a supplier when monitoring ormanaging sales order status.

Allocation status and shipment status are shown. Backorder and otherexceptions for the sales order are shown. Order fulfillment is performedfrom this screen.

The sales order queue includes a workflow tab 5305 to navigate throughthe workflow options. An approval filter 5310 allows sales orders to befiltered. A ‘my sales orders’ menu 5315 shows sales orders associatedwith a particular user. An open sales orders menu shows sales ordersthat are in progress. The sales orders menus include fields for salesorder information 5328, purchase order number 5330, department 5332,priority 5334, date/time 5336, buyer information 5338, assigneeinformation 5340, allocation information 5340, warning information 5344,shipment status information 5346, assignment information 5348, and aselect box 5350.

FIG. 54 is an exemplary screenshot 5400 of a picking/packing slip. Thisslip menu shows where items are to be picked from within the internalstockroom, and shows delivery information and line item status. The menuis generated at the eProcurement server 20, in some embodimentsaccessing the purchase order database 2500, and is accessed by a user atthe purchaser responsible for receiving ordered (fulfilled) items whenthey arrive in stock.

Location field 5405 shows the location of the internal stockroom. Buyerwindow 5415 shows buyer information. Ship to window 5420 shows shippinginformation; here it is the same as the supplier (internal stockroom).Bill-to window 5425 shows billing information, here it is the same asthe supplier. Line item window 5430 gives a line item description ofitems ordered.

FIG. 55 illustrates an exemplary contract history interface inaccordance with the present invention. The contract history interface5500 may include, for example, a contract history tool 5501 for trackingand viewing contractual amendments or events. The contract history tool5501 may be implemented via the contract engine 1554 (or, morespecifically, for example, the contract management engine 1688, 1784). Auser or organization may use the contract history tool 5501 forhistorical tracking or auditing purposes. The contract history tool 5001may include, for example, a contract history feature 5503 for actualviewing or access to the contractual amendment or events associated withone or more contracts 5504. The tool 5001 may also be used for exporting(e.g., downloading or transmitting via other electronic communicationmeans) contract history(ies) for tracking or auditing purposes.Moreover, a contract history search tool 5502 may be used to search forcontracts based on type, date, user, organization, supplier,effective/expiration date(s), tier(s), ceiling(s)/limit(s), or item(s).Once the search engine 22 receives the appropriate search query from thecontract history tool 5502, contract history search results may bepresented via the interface 5500.

The purchase order status/acknowledgement includes workflow tabs 5505and 5510 to navigate through the workflow options. General informationwindow 5515 gives details regarding an order, and document status window5530 gives details of documents relating to the order. A line itemstatus window 5520 shows the status of each line item. A backorderwarning field 5525 shows that an item is backordered.

FIG. 56 is an exemplary screenshot 5600 of a replenishment report. Themenu is generated at the eProcurement server 20, in some embodiments bythe purchasing engine 1681 accessing requisition database 2700, and isaccessed by a user at the purchaser when managing the inventory ofitems. This menu shows all items requiring replenishment (restocking).The quantity to order based on inventory parameters (MAX, ROP, EOQ),quantity on hand, on order, and backordered, is automatically populatedinto a purchase request. In some embodiments the automatic population isperformed by a robot as described in FIG. 75. In some embodiments, thisautomatic population is performed by Invoice, PO, Order, RequisitionModule (2082, FIG. 20).

The replenishment report includes menu tab 5605 to navigate through thereplenishment options. Quantity on hand field 5620, quantity on orderfield 5622, pending sales order field 5624, quantity on backorder field5626, preferred supplier field 5628, preferred item number field 5630,price field 5632, quantity box 5634, and add to cart icon 5636 are alsoshown.

FIG. 57 is an exemplary screenshot 5700 of a replenishment order. Thismenu shows an order marked as a replenishment order. The order isgenerated at the eProcurement server 20, in some embodiments by therequisition fulfillment engine 1686 accessing requisition database 2700,and is accessed by a user at the purchaser responsible for replenishinginventory items. This order lists inventory item and location where theitem is being stocked. Stocked unit conversion can be overridden fromitem default. For example, conversion may be performed from unitsordered, such as case to units sold, where a case of 24 is sold in unitsof each.

Product description line item 5710 gives details of a particularproduct. A replenish stock box 5715 allows stock to be automaticallyreplenished. A supplier field shows that the supplier is an internalstockroom. A stocked units box 5735 allows a user to enter the number ofitems to be kept in stock.

FIG. 58A illustrates an exemplary contract view interface in accordancewith the present invention. The contract view interface 5800 mayinclude, for example, a contract view tool 5801 for viewing detailedinformation regarding a contract. The contract view tool 5801 may beimplemented via the contract engine 1554 (or, more specifically, forexample, the contract management engine 1688, 1784); a contract viewedusing the contract view tool 5801 may be stored in the transactionsdatabase 228 and, more specifically, the contracts database 3200. Thecontract view tool 5801 may include, for example, a contract informationfeature 5802 or also a contract controls feature 5803. The contractinformation feature 5802 may include, for example, a general informationfeature 5804 for displaying general information elements like, forexample, a contract name, a contract number, a supplier name associatedwith the contract, an active/inactive flag for indicating whether acontract is currently in an active or inactive state, an applyautomatically flag for indicating whether amendments or contractualevents associated with the contract are applied automatically, adescription of the contract, or an effective and expiration dateassociated with the contract; the contract information feature 5802 mayalso include, for example, a detailed information feature 5805 fordisplaying detailed information (see above; FIG. 40) like, for example,a hard copy location of a contract, a soft copy location of a contract,any supporting documents associated with the contract, a projectedsavings percentage/amount associated with the contract, or a contracttype associated with the contract; the contract information feature 5802may further include, for example, a budget information feature 5806 fordisplaying budget information (see above; FIG. 52) like, for example, abudget total amount, whether the contract has multiple tiers, an actualpurchase requisitions amount associated with the contract, an actualpurchase order amount associated with the contract, or an invoice actualamount associated with the contract; or, the contract informationfeature 5802 may further include, for example, a blanket purchase order(PO) information feature 5807 for displaying blanket PO informationlike, for example, a blanket PO number to use for a contract. Moreover,the contract controls feature 5803 (see above; FIG. 51) may provideinformation related to who may exercise some level of control over acontract. The contract controls feature 5803 may include, for example, acontracts owners information feature 5808 for displaying informationassociated with who the contract owners may be, an applicable usersfeature 5809 for displaying elements indicating whether the contract maybe used only by owners (or, other as well) and whether/which departments(see above; FIG. 53) may access the contract, an applicable productsfeature 5810 for displaying a fulfillment address (see above; FIG. 54)that may be associated with products associated with the contract, a POclauses feature 5811 for displaying any applicable PO clauses (seeabove; FIG. 49) that may be associated with the contract, or a formsfeature 5812 for displaying any forms that may be associated with thecontract (see above; FIG. 50).

FIG. 58A is an exemplary screenshot 5800 of a replenishment receipt.This receipt is generated at the eProcurement server 20, in someembodiments by the requisition fulfillment engine 1686 accessing thereceipt database 2800, and is accessed by a user at the purchaserresponsible for replenishing inventory items. This menu showsreplenishment details, and the default location for an item isautomatically populated. In some embodiments, upon receipt, items areautomatically placed into inventory in their appropriate location. Insome embodiments, items are physically placed (e.g., by an operator witha forklift) into a physical inventory location (e.g., a stockroom orwarehouse) and the electronic procurement system is updated accordingly.In some embodiments, an item count is just updated in the electronicprocurement system, without any corresponding physical movement of theitem by an operator.

The replenishment receipt includes menu tabs 5805 and 5820 to navigatethrough the receiving options. Add purchase order button 5810 allows apurchase order to be added. Save updates button 5812 allows changes tobe saved. Complete button 5814 allows a user to indicate that thereceipt is complete. A purchase order number field 5825 specifies thepurchase order. The purchase order includes details such as PO linenumber, product name, catalog number, quantity or units of measure,previous receipts, and quantity ordered. Additional information such asstocked item information (item, item number, stocked units) is shown,along with fulfillment center information (e.g., surplus store) and lottracking information.

As described, the receipt replenishment may be performed using thereceipt database 2800, including Receipt Line Inventory Replenishment2818, in some embodiments an inventory replenishment line for a receipt.

FIG. 58B is an exemplary screenshot 5850 of a replenishment allocation.This allocation is generated at the eProcurement server 20, in someembodiments by the purchasing engine 1681 accessing the requisitiondatabase 2700, and is accessed by a user at the purchaser responsiblefor replenishing inventory items. This menu shows that sales orderspending backorder for an item are automatically allocated inventory uponreceipt of the new inventory.

A create quantity receipt 5852 button and create cost receipt button5854 allow a user to create receipts based on quantity or costrespectively. Receipt number field 5860 shows that a receipt has beencreated for a particular PO number. Allocation menu 5870 shows ordersthat have been allocated, including sales order number, PO number,stocked item, stocked item number, quantity ordered, and quantityallocated.

FIG. 59 illustrates an exemplary contract pricing interface inaccordance with the present invention. The contract pricing interface5900 may include, for example, a contract pricing tool 5907. Thecontract pricing tool 5907 may be implemented via the contract engine1554 (or, more specifically, for example, the contract management engine1688, 1784). Furthermore, the contract pricing tool 5907 may display,for one or more selected items/products, the pricing available to aspecific user/organization. To access the contract pricing tool 5907associated with one or more items/products, a user may first search forthe item/product via a product search tool 5901 that may present theuser with additional search tools 5902; the product search tool 5901 andits additional search tools 5902 may send search queries (e.g.,filtering by supplier 5903, filtering by item/product category 5904,and/or product searching 5905) to the search engine 22 for the searchengine to execute against one or more respective databases (e.g., masterproduct database 236, transaction database 228, or more specificdatabases); search results 5906 are then returned and presented; bydefault, the lowest price for each item/product may be displayed insearch results. Once a user has selected one or more items/products andinvoked a select price or contract feature, then the user may access thecontract pricing tool 5907. Like the search results 5906, by default,the contract pricing tool 5907 may display the lowest price for one ormore items/products selected and available 5908 to a user (the tool 5907may also display any discounts related to a price set); available pricesmay be organized according to owner price, department price,organization price, corporate list price, or an option for setting amanual price (in an appropriate currency) 5909. Thus, one or more pricesmay be assigned to the same contract but may be available to variouslevels of users, departments, organizations (may include a corporatelist price), or may be manually set by each in accordance with userprivileges or business rules. A user may select a specific price andproceed to checkout via the cart feature; the price selected for theitem/product of a contract may further be applied to the user,department or organization in accordance with user privileges orbusiness rules.

FIG. 59A is an exemplary screenshot 5900 of a setup folders/automatedrobots screen. In some embodiments, a robot is an automated set ofinstructions for performing a specific task, and for supporting thevarious workflow processes. Several robots exits to perform varioustasks. In some embodiments robots are created by the electronicprocurement system (or system vendor or creator) and may not be editedby a user. In some embodiments robots, or parameters of the robot, maybe edited by a user. Exemplary robots and their tasks are described withregard to FIG. 75. In some embodiment, a robot may perform functionsfrom a script of operations. In some embodiments, a folder is anapproval queue within a system. In some embodiments, one or moreapprovers are assigned to folders, and they are notified when documentsare placed within the folder(s) for their review and/or approval. Insome embodiments folders, or parameters of the folder, may be edited bya user.

This screen is generated at the eProcurement server 20, in someembodiments by sales/purchase management module 2046 (FIG. 20) incoordination with information stored in the buyer invoice database 3300and/or sales invoice database 3400 (FIG. 22), accessed by invoicerequisition module 2082 (FIG. 20). This screen is presented to a userdeveloping workflow functions and importing or exporting them. In otherembodiments, the screens, workflows, folders, and rules described in thefollowing figures could apply to any transaction workflow, such as apurchase workflow, a sales workflow, an invoice workflow, a paymentworkflow, a shipping workflow, or any other type of transactionworkflow.

FIG. 59A shows an invoice menu tab 5902, including a workflow folderimport/export tab 5904. A window 5905 is associated with theimport/export tab 5904. This window 5905 includes an export button 5910that allows a user to export a workflow e.g., to a web location, to afile, to a library, to local storage, etc. The window 5905 includes abrowse button 5912 that enables a user to select folders or robots toimport. The window 5905 includes a load folders/robots button 5914, insome embodiments to import an invoice workflow electronic file,including a folders, and/or a robots file. These folders and robots canbe imported (e.g., from a web location, a file, a library, a localstorage, or a combination of these etc.) and exported (e.g., from thelocations described) to facilitate the setup of the invoice workflow.Additionally, folders and robots can be ported via electronic filebetween application environments, e.g. test to production. In someembodiments, a test environment is a ‘safe’ environment where newworkflows, rules, folders and robots may be created, tested, andverified. When a user is satisfied that the new workflow, etc. isfunctional and ready for use, the user can then enable the new workflowand put it into production. This may be referred to as moving from testto production.

Thus, a user can develop the functions he needs and test them in a safe(i.e., development) environment, and when the test is successful, portthe functions to the active workflow for normal use. An example of thisworkflow development is illustrated in FIGS. 44-48, and describedaccordingly. In some embodiments, the folders and/or robots are XMLbased files. In other embodiments, the folders and/or robots could be inother related languages such as hypertext markup language (HTML), commaseparated variables (CSV), tab delimited text files, name value pairs,or any other markup language, or text based language.

FIG. 59B is an exemplary screenshot 5920 of a setup workflow processscreen. This screen is generated at the eProcurement server 20, in someembodiments by sales/purchase management module 2046 (FIG. 20), asdescribed with reference to FIG. 59A. This screen is presented to a userdeveloping workflow functions and specifying rules associated with theworkflow functions.

FIG. 59B includes a workflow configuration menu tab 5921 and itsassociated window 5122. The window 5122 may include an active versionwindow 5924, a process id window 5928, a steps window 5931, and anactivities window 5940. The workflow configuration menu tab 5921 mayinclude an import tab 5921 and an export tab 5946, for importing andexporting folders and/or robots to and from the workflow, as described.

A active version window 5924 displays a list of workflow versions, andshows the active version. In some embodiment, a user may have one ormore versions of a workflow, and may have the option of activating ordeactivating versions in order to test a newer version or to revert toan older workflow version. In some embodiments, a user has an option ofcreating a new version or deleting one or more versions of a workflow.In some embodiments, a user may save a current workflow as a newworkflow version, so that the user can edit it but leave the originalversion intact.

A process id window 5928 shows a process identifier, version, creationdate, user defined description, and active status, along with savebutton 5930 for saving changes to the workflow. A steps window 5931shows exemplary steps or operations in the workflow robot and/or folder,including non-purchase order approvals 5932, auto-matching (e.g., ofinvoices to purchase documents) 5934, matching exceptions 5936, and OK(approval) to pay 5938. In some embodiments, more or fewer operationsmay be specified. In some embodiments, non-purchase order approval is anapproval for a purchase request that does not have an associatedpurchaser order. In some embodiments, auto-matching is a process wherebya first document (e.g., a an invoice) is compared to a correspondingsecond document (e.g., a purchase request or purchase order) to find ifthe amounts, quantities, etc. on the first document and second documentcorrespond. In some embodiments, there may be a tolerance level (e.g.,measured in dollar value, percentage of invoice total, percentage ofquantity, etc.) within which a match is deemed acceptable. For example,a tolerance of 1% might be permitted on a shipment of items, so that ifthe invoice and purchase order totals fall within this tolerance rangeof 1%, the match is deemed acceptable. In some embodiments, a defaulttolerance range may be provided by the electronic procurement system. Insome embodiments, a user may select one or more tolerance values orranges according to his preferences.

A practical example of where this tolerance would be valuable is where auser orders several items and the shipping cost varies from an expectedshipping cost due to (for example) a weight of the items. In thisexample, a user would probably consider the order satisfied (e.g., amatch) even if the shipping cost is slightly different from expected,within a tolerance range. In another example, if a tax rate (e.g., astate sales tax rate) changes slightly, a user would probably considerthe order satisfied (e.g., a match) if the invoice price is slightlydifferent from expected due to the change in tax rate, within atolerance range. In another example, if a first type of unit (e.g. 12 ozbeaker) is ordered, but a second item (e.g., 12.5 oz beaker) isdelivered, and the delivered beaker is within the cost and/or othertolerance range set by the user, then the order is satisfied (e.g., amatch).

An activities window 5940 shows activity names and rules associated witheach of the steps. A start instruction 5942 and an end instruction 5944specify a start and an end respectively for steps associated with afolder and/or robot. A set of rules 5943A-D describe exemplary rules andconditions associated with them for processing invoices (e.g., purchaseinvoices and/or sales invoices).

In an exemplary embodiment, rule 5942A determines if a document needs tobe submitted for a non-purchase order approval, i.e., for approvaloutside of the regular approval process. In an example, rule 5942Aindicates that if a document (e.g., an invoice, a purchase order,purchase requisition, or any other document) has non-purchase orderlines (value is true) then the non-purchase order approval workflow isstarted. In some embodiments, having non-purchase order lines means thata field (e.g., in a database associated with the document) indicatesthat non-purchase order lines are present, or alternatively, uponrunning a function on the database, it returns a result indicating thatnon-purchase order lines are present.

In an exemplary embodiment, rule 5942B determines automatic matching ofinvoices and purchase documents. In an example, rule 5942B indicatesthat if a document (e.g., an invoice, a purchase order, purchaserequisition, or any other document) does not (value is false) havenon-purchaser order lines (as described above) then an automaticmatching workflow is started.

In an exemplary embodiment, rule 5942C determines matching exceptionsbetween (for example) invoices and purchase documents. A matchingexception is where (for example) an invoice does not correspond to(match up with) a purchase document, within a specified tolerance range,as described. In an example, if a matching status field (e.g. matchstatus) of a database associated with the document (e.g. document) has avalue of unmatched, and is not within a tolerance value of the document(e.g., tolerance status), then a document exception workflow is started.

In an exemplary embodiment, rule 5942D determines if an invoice paymentworkflow (e.g., OK to Pay) is to be started. In an example, rule 5942Dindicates that if a match status field (e.g., match status) in adatabase associated with the document or a returned value from afunction performed on the database, has a value of “matched,” or if amatch status field (or returned value) has a status of “do not match,”then the invoice payment workflow is started. This means that if adocument (e.g., an invoice) is matched, or if the document indicatesthat no match is required, then the document should be paid.

In some embodiments, exemplary rules and conditions may be described forprocessing other business documents such as purchase orders, purchaserequisitions, credit memos, receipts, contracts, tax documents,employment documents, or any other financial, governmental, ortransactional document.

In some embodiments, the rules are logical statements which, if met,cause the step to be executed. In some embodiments, more complex logicalor programming instructions may be used to implement rules in theworkflow folder and/or robot.

The setup workflow process of FIG. 59B allows for the creation of aunique workflow process for invoices and credit memos based on thecustomer's business processes. The invoice workflow steps are steps thatwill be visible to end users of the system. In some embodiments, othersteps that are only visible to a super-user or system administrator maybe specified also. The invoice activities window 5940 allows theadministrator or super-user to view the workflow steps and the rulesassociated with each step. The activities have rules that define whichdocuments will fall into the activity. The invoice workflowconfiguration can be imported/exported to facilitate the setup ofinvoice workflow. Additionally, invoice workflow configurations can beported via electronic file between application environments, e.g. fromtest to production, as discussed. In some embodiments, this file isXML-based, as described.

FIG. 59C shows an exemplary screenshot 5950 of an assign approversscreen. This screen is generated at the eProcurement server 20, in someembodiments by sales/purchase management module 2046 (FIG. 20), asdescribed with reference to FIG. 59A. In some embodiments, this screenis displayed to a super-user to assign one or more approvers for aworkflow folder. In some embodiments, this screen is displayed to anapprover to assign one or more approvers for an invoice.

FIG. 59C includes a shared workflow folders menu tab 5952, with anassociated window 5953. The window 5953 includes an apply all changesbutton 5953, for applying changes made in the window. The window 5953also includes a create new folder button 5954 to allow a user to createa new folder and/or robot to implement a rule, as described. Exemplaryfolders include matching exception(s), non-purchase order approvals,remit to validation, and others. The window 5953 includes a selectedfolder window 5958 that shows a folder currently selected (e.g.,“matching exception” in this example) by the user and a save button 5960allows a user to make changes to that folder. As described, the matchingexception rule is invoked when the system fails to find a match betweendocuments, e.g., between a purchase document and an invoice. In someembodiments, a matching exception may check for matches between three ormore documents (e.g. between a purchase order, an invoice, and adelivery slip) and if all three fail to match, then report a matchingexception. In some embodiments, an auto-matching function can check formatches between three or more documents, and, if all three match,approve a document (e.g., an invoice) for payment.

An add user button 5962 allows an administrator or super-user to addapprovers to a folder and/or robot in the selected folder window 5958above. In some embodiments, the approver user information includesapprover name 5964, user name 5966, approver email 5968, and approverphone 5970. In some embodiments, a remove button 5972 allows anadministrator or super-user to remove an approver.

This screen of FIG. 59C allows a user to assign approvers to sharedworkflow folders. This assignment allows approvers to distribute theapproval workload among themselves, which will lead to overall fasterapprovals as bottlenecks are likely to be eliminated.

FIG. 59D shows an exemplary screenshot 5975 of a review requiredapprovals screen. This screen is generated at the eProcurement server20, in some embodiments by sales/purchase management module 2046 (FIG.20), as described with reference to FIG. 59A. This screen is displayedto a user wishing to see the status of a document (e.g., an invoice) inthe workflow as it is being processed.

FIG. 59D includes a settlement menu tab 5976, including an invoicehistory menu tab 5977. This invoice history tab includes informationsuch as invoice number, supplier invoice number, supplier name, and alsoincludes a drop down menu 5978 for performing available actions (e.g.,perform matching). An approvals menu tab 5980 shows at what stage in theapprovals process an invoice is currently active. Approvals stagesinclude invoice submitted 5982, auto matching performed 5984, matchingexceptions resolved 5986, and invoice completed 5988. In someembodiments, more or fewer stages are possible, depending on the numberof steps in the folders and/or robots specified.

In some embodiments, the screen of FIG. 59D allows the user to view thecurrent state of the document within invoice workflow. This screen showsthe completed, active and pending steps. In some embodiments, anotherstep shows the assigned approver associated with an invoice. In someembodiments, the screen shows a plurality of tabs representing buyerinvoice 5979, approvals 5980, matching 5981, and history 5983. The buyerinvoice tab 5979 represents a buyer invoice to be approved for payment.The approvals tab 5980 represents the approvals and matching processshown in FIG. 59D. The matching tab 5981 represents matching documentscorresponding to the buyer invoice. The history tab 5983 represents ahistory of events associated with the buyer invoice.

FIG. 59E shows an exemplary screenshot 5990 of a “review invoicesrequiring approval screen.” This screen is generated at the eProcurementserver 20, in some embodiments by sales/purchase management module 2046(FIG. 20), as described with reference to FIG. 59A. This screen ispresented to an approver checking the status of invoices assigned tohim/her for review/approval.

FIG. 59E includes an approvals menu tab 5991, including an invoice menutab 5999. The invoice menu tab includes a toolbar 5992 to filter invoiceapprovals provided to the user approver (in some embodiments with suboptions to show invoice details and assign substitute approvers), and adrop down menu 5995 to apply actions to selected invoices (e.g.,approve/complete invoice). In some embodiments, the filtering includesshowing invoices that are approved, or showing invoices that are notapproved, or a combination thereof. In some embodiments, the filteringincludes showing invoices that are assigned to the user, showinginvoices that are assigned to a pool of approvers, showing invoices forwhich the user is a substitute approver, or a combination thereof.

A window 5993 shows a ‘my invoice approvals’ personal folder, showinginvoice approvals associated with the current user. The invoiceapprovals may in some embodiments include one or more details such asinvoice number, state (e.g., active, inactive, etc.), supplier invoicenumber, supplier name, invoice date, invoice type, amount of invoice,due date, discount date (date by which if paid, a discount is applied),action (e.g. approve, deny, etc.), and a select box 5996 for indicatingthat an action (e.g., from drop down menu 5995) should be performed onthe invoice. A matching exceptions window 5994 shows matching exceptionsfor invoices and the approval state, approver, supplier, invoice and duedates, amount, and discount date associated with each invoice, and aselect box indicating that an action (e.g., from drop down menu 5995)should be performed to the invoice.

The matching exceptions window 5994 may show an invoice (e.g., referenceI-00128) with a status ‘assigned’ that has been assigned to the user, asshown in the ‘My Invoice Approvals’ window 5993. The matching exceptionswindow 5997 may also show other non-assigned invoices (e.g., thoselisted below the assigned invoice I-00128 in window 5994).

In some embodiments, this window 5994 is a shared approver folder, inwhich a plurality of approvers 5997 may review invoices and makeapproval decisions regarding them. This shared approver folder may helpreduce bottlenecks in the system if one approver is unavailable or toobusy to approve invoices, by sharing the workload among other approvers.Apply action button 5998 chooses an action to apply to a selectedinvoice.

The “review invoices requiring approval” screen of FIG. 59E allows theapprover to view their personal workflow approval list, e.g. thedocuments currently assigned to them for review. This screen allows theapprover to view all shared folders assigned to them as part of theWorkflow Setup process. In some embodiments, a user or users have thecapabilities to perform from such a screen one or more of: approving orcompleting invoices, rejecting invoices, placing documents (invoices) onhold, and forwarding invoices to other approvers. In some embodiments,substitute approvers may be assigned to personal and shared folders. Insome embodiments, users with advanced management permissions (superusers or administrators) may manage folders and documents on behalf ofother approvers.

FIG. 60 is a flowchart representing a server method 6000 for hosting aneProcurement system, according to certain embodiments of the invention.The server method 6000 may be governed by instructions that are storedin a computer readable storage medium and that are executed by one ormore processors of one or more servers. Each of the operations shown inFIG. 60 may correspond to instructions stored in a computer memory orcomputer readable storage medium. The computer readable storage mediummay include a magnetic or optical disk storage device, solid statestorage devices such as flash memory, or other non-volatile memorydevice or devices. The computer readable instructions stored on thecomputer readable storage medium are in source code, assembly languagecode, object code, or other instruction format that is interpreted byone or more processors. In the following flowchart, dashed line boxesindicate optional operations or steps that may be implemented in someembodiments.

In the following descriptions and embodiments, purchase orders may beaccessed in purchase orders database (FIG. 22, 2500), requisitions maybe accessed in requisitions database (FIG. 22, 2700) invoices may beaccessed in buyers invoice database (FIG. 22, 3300) and sales invoicedatabase (FIG. 22, 3400), and business rules may be accessed in abusiness rules database, all as described. The databases may be accessedby database and management module (FIG. 20, 2070) and invoice, purchaseorder, order and requisition module (FIG. 20, 2082).

In some embodiments, the server method 6000 includes the followingoperations, performed at a server hosting an electronic procurementsystem. The server method includes associating business rules with aplurality of users (6002). One or more catalog items are displayed(6004) to a respective user in accordance with the respective businessrules associated with that user. In some embodiments, approval of apurchase requisition is determined (6006) for a displayed catalog item.A purchase order is generated (6008), in some embodiments for thepurchase requisition, and/or in some embodiments for a displayed item.

In some embodiments, the business rules are specified by a super-user(6019). In some embodiments, the business rules are stored at the server(6020). In some embodiments, the purchase documents (including purchaserequisition and purchase order) are stored at the server (6021). In someembodiments, the business rules include a procurement policy andpurchasing permissions (6024). In some embodiments, the purchasingpermissions include purchasing approval ability and purchasing limitability (6026).

In some embodiments, the business rules may be customized according toat least one of a group consisting of by user, by role, and/or bydepartment (6028). In some embodiments, approval by a user of his or herown purchase request may be prevented in accordance with the businessrules (6030). In some embodiments, approval by a user of his or her ownpurchase request over a spending limit may be prevented in accordancewith the business rules (6032). In some embodiments, the systemdetermines from which supplier items are ordered in accordance with theprocurement policy and contractual agreements (6034).

FIG. 61 is a flowchart 6100, continuing the flowchart of FIG. 60. Insome embodiments, the electronic procurement system is a single instancemulti-tenant system (6110). In some embodiments, the electronicprocurement system is a web-based system (6112). In some embodiments,the server is located independently from suppliers and purchasers of theelectronic procurement system (6114). In some embodiments, the server islocated at a supplier of the electronic procurement system (6116). Insome embodiments, the server is located at a purchaser of the electronicprocurement system (6118). These features of FIG. 61 apply in part or inwhole to all systems described here, including systems 6900, 7000, 7100as described.

In some embodiments, displaying catalog items in accordance withbusiness rules comprises preferentially displaying items based on quotasof purchases to be filled (6120). In some embodiments, generating apurchase order includes associating workflow rules with the purchaseorder, in accordance with business rules (6122).

FIG. 62 is a flowchart representing a server method 6200 for hosting aneProcurement system, according to certain embodiments of the invention.The server method 6200 may be governed by instructions that are storedin a computer readable storage medium, as described.

In some embodiments, server method 6200 includes the followingoperations. Business rules are associated (6202) with a plurality ofcatalog items. In some embodiments, the business rules are associatedwith a supplier. One or more catalog items are displayed (6204) to arespective user in accordance with the respective business rulesassociated with the respective catalog items. In some embodiments, thedisplay is in accordance with business rules associated with a supplier.In some embodiments, approval is determined (6206) for a purchaserequisition for a displayed catalog item. A purchase order is generated(6208), in some embodiments for the purchase requisition and/or in someembodiments for a displayed item.

In some embodiments, purchasing status is displayed for the purchaserequisition (6210). In some embodiments, purchasing status is displayedfor the purchase order. In some embodiments, displaying includespresenting on a graphical dashboard approval, purchasing, andfulfillment status for the item (6212).

In some embodiments, the graphical dashboard is dynamically generated atthe server in accordance with business rules stored at the server(6214). In some embodiments, purchasing status is displayed for ashopping cart associated with the purchase requisition (6216). In someembodiments, purchasing status is displayed for a purchase orderassociated with the purchase requisition (6218).

FIG. 63 is a flowchart representing a server method 6300 for hosting aneProcurement system, according to certain embodiments of the invention.The server method 6300 may be governed by instructions that are storedin a computer readable storage medium, as described.

In some embodiments, server method 6300 includes the following,performed at a server hosting an electronic procurement system. A secondavailable catalog item is identified (6302) corresponding to a firstcatalog item, in response to a user request to access the first catalogitem associated with the electronic procurement system, wherein thefirst catalog item is unavailable. The second available catalog item isdisplayed (6304) to the user in accordance with business rulesassociated with the user. In some embodiments, approval of a purchaserequisition is determined (6306) for the displayed catalog item. Apurchase order is generated (6308), in some embodiments for the purchaserequisition, and/or in some embodiments for a displayed item.

In some embodiments, the business rules associated with the user aredetermined by a super user (6310). In some embodiments, the super useris at an organization associated with the user. In some embodiments, thebusiness rules associated with the user are stored at the server hostingthe electronic procurement system (6312).

In some embodiments, the electronic procurement system includes aplurality of suppliers, at least one of the suppliers having a catalog(6314). In some embodiments, the electronic procurement system includesa plurality of purchasing organizations, each having at least one user,with permissions associated with the at least one user (6316). In someembodiments, the permissions are determined in accordance with businessrules (6318). In some embodiments, the permissions are determined by asuper user (6320). In some embodiments, the permissions associated withthe at least one user determine the user's ability to purchase from thecatalogs associated with the plurality of suppliers (6322).

FIG. 64 is a flowchart representing a server method 6400 for hosting aneProcurement system, according to certain embodiments of the invention.The server method 6400 may be governed by instructions that are storedin a computer readable storage medium, as described.

In some embodiments, server method 6400 includes the followingoperations. A first user purchase request to purchase an item and asecond user purchase request to purchase the same item are received(6402). A determination is made (6404) if there is sufficient stock ofthe item available to fulfill both user purchase requests. User purchaserequests are prioritized (6406) if there is insufficient stock of theitem available to fulfill both purchase requests. A purchase order isgenerated (6408) for at least one of the user purchase requests inaccordance with the prioritizing.

In some embodiments, the electronic procurement system is a singleinstance multi-tenant system (6418). In some embodiments, the serversystem includes a plurality of purchasing organizations, each purchasingorganization having a plurality of associated users. In someembodiments, prioritizing the user purchase requests is performed inaccordance with business rules (6410). In some embodiments, prioritizingthe user purchase requests is performed in accordance with positions ofthe users on a management hierarchy (6412). In some embodiments,prioritizing the user purchase requests is performed in accordance withthe importance of a respective project associated with a user (6414).

In some embodiments, user purchase requests of a similar priority levelare fulfilled according to a first in, first out (FIFO) method (6420).In some embodiments both user purchase requests are placed in a queueaccording to the prioritizing (6422). In some embodiments user purchaserequests of a similar priority level in the queue are fulfilledaccording to a first in, first out (FIFO) method (6424). In someembodiments, a FIFO method is used for filling purchase orders in queue,but a user's order of insertion in the queue is determined byprioritizing.

In some embodiments, one or more users having an order in the queue arenotified when the ordered item is ready for fulfillment (6426). In someembodiments, an alternative available item is presented to a user havingan order in the queue, in accordance with a predicted fulfillment delay(6428). In some embodiments, if a user has placed an order, and theorder is delayed or expected to be delayed, an alternative item ispresented to the user for selection.

In some embodiments, prioritizing is performed according to feesassociated with the respective users (6416).

FIG. 65 is a flowchart representing a server method 6500 for hosting aneProcurement system, according to certain embodiments of the invention.The server method 6500 may be governed by instructions that are storedin a computer readable storage medium, as described.

In some embodiments, the server method 6500 includes the following,performed at a server hosting an electronic procurement system. A firstuser purchase request to purchase an item associated with the electronicprocurement system and a second user purchase request to purchase thesame item are received (6502). A determination is made (6504) upondelivery of the item whether there is sufficient stock of the itemavailable to fulfill both user purchase requests. The user purchaserequests are prioritized (6506) based on the determining. Theprioritized user purchase requests are fulfilled (6508) in accordancewith priority. In some embodiments, prioritizing includes determiningwhich request is the most important or highest priority.

In some embodiments, if, at time of delivery, an alternative itemcomparable with the requested item is available, and the requested itemis not available in sufficient stock to satisfy both the first user andsecond user, one or more of the user purchase requests are fulfilledwith the alternative item 6510.

FIG. 66 is a flowchart representing a server method 6600 for hosting aneProcurement system, according to certain embodiments of the invention.The server method 6600 may be governed by instructions that are storedin a computer readable storage medium, as described.

In some embodiments, the server method 6600 includes the following,performed at a server hosting an electronic procurement system. A seriesof user purchases of an item is analyzed (6602). A property per itempurchased in the series is determined (6604). An inventory of the itemis managed based on the property per item (6606).

In some embodiments, the property per item is a cost per unit of itempurchased (6610). In some embodiments, the cost per item includes theholding cost per unit of that item (6612). In some embodiments, theholding cost includes depreciation. In some embodiments, the holdingcost includes interest expense.

In some embodiments, managing includes determining a selling price perunit of the item, based on the cost per unit of the item and a markup(6614). In some embodiments, the property per item is a spoilage status,based upon average holding time per item (6616). In some embodiments,the spoilage status is a ‘best before’ date for food, medicines, orother organic items. In some embodiments, the property per item isvelocity of purchases for that item (6618). In some embodiments, theproperty per item is a predicted out-of-stock time based upon thevelocity of purchases and a velocity of sales (6620).

FIG. 67 is a flowchart representing a server method 6700 for hosting aneProcurement system, according to certain embodiments of the invention.The server method 6700 may be governed by instructions that are storedin a computer readable storage medium, as described.

In some embodiments, the server method 6700 includes the following,performed at server hosting an electronic procurement system. Inresponse to receiving an invoice (e.g., stored in sales invoice database3400, or buyer invoice database 3300, FIG. 22), a purchase document(e.g., from purchase order database 2500 or purchase request database2700, FIG. 22) corresponding to the invoice is identified (6702), forexample by sales/purchasing management module 2046, FIG. 20. Contents ofthe purchase document are compared (e.g., auto-matching 5984, andperform matching action 5978, FIG. 59D) against contents of the invoice(6704). A discrepancy (e.g., matching exception 5986, FIG. 59D) betweenthe purchase document and the invoice is identified (6706). Anotification is generated based upon the identified discrepancy (6708).In some embodiments, the invoice is provided by a supplier to theelectronic procurement system. In some embodiments, the purchasedocument is a purchase order or a purchase requisition.

In some embodiments, the comparing is performed by comparing fields ofthe buyer invoice database 3300 and/or seller invoice database 3400 withcorresponding fields from the purchase order database 2500, all in FIG.22. In some embodiments, these fields include one or more of PurchaseOrder Workflow Activity History 2510, Supplier 2532, Purchase Order LineProduct 2548, and/or Purchase Order User Selected Approver 2562, all inFIG. 25. The selected fields are exemplary, and in other embodiments adifferent selection of fields could be compared.

In some embodiments, comparing contents includes performing at least atwo way match (e.g., auto-match 5984, FIG. 59D) between the invoice andthe purchase document (6170). In some embodiments, at least a two waymatch includes a two way match and a three way match. In someembodiments, generating a notification includes notifying a user (e.g.,matching exceptions 5994) associated with the purchase of the match(6722). In some embodiments, approval is requested from the user thatthe match is correct (6724). In some embodiments, approval is requestedfrom the user to pay the invoice (6726), e.g., approve box 5996, FIG.59E. In some embodiments, identifying a discrepancy includes determiningif a property associated with the invoice is outside of a tolerancerange (6712). In some embodiments, the tolerance range is specified bybusiness rules (6714). In some embodiments, the property includes atleast one selected from a group consisting of price, quantity, deliverydate, and/or delivery quality (6716).

In some embodiments, generating a notification includes notifying thesupplier that the invoice is in dispute (6728). In some embodiments, thesupplier and a purchaser associated with the invoice are provided withaccess to an online dispute resolution mechanism (6732). In someembodiments, the online dispute resolution mechanism is hosted withinthe electronic procurement system (6734).

In some embodiments, a receipt (e.g., from receipt database 2800) isgenerated for payment towards the invoice if the value of the invoice isover a threshold (6736).

In some embodiments, identifying a discrepancy includes determining ifan alternative item comparable with the requested item has beendelivered (6718). In some embodiments, a determination is made whetherthe purchase order has been satisfied by the alternative item (6720). Insome embodiments, comparing contents includes performing at least athree way match between the invoice and a purchase order and a purchaserequisition (6738).

FIG. 68 is a flowchart representing a server method 6800 for hosting aneProcurement system, according to certain embodiments of the invention.The server method 6800 may be governed by instructions that are storedin a computer readable storage medium, as described. In someembodiments, server method 6800 includes the following, performed atserver hosting an electronic procurement system. In response toreceiving an invoice, a purchase document corresponding to the invoiceis identified (6802). The invoice and the purchase document are linked(6804). The invoice and the purchase document are presented (e.g. 5995,FIG. 59E) for payment approval (6806).

In some embodiments, the identifying operation (6802) is performed bycomparing fields of the buyer invoice database 3300 and/or sellerinvoice database 3400 with corresponding fields from the purchase orderdatabase 2500 and/or purchase requisition database 2700, as described inFIG. 22.

In some embodiments, the linking and presenting for approval isperformed by associating the buyer invoice database 3300 and/or sellerinvoice database 3400 with the purchase order database 2500 and/orpurchase requisition database 2700. When the invoice is presented forapproval, the associated purchase document is retrieved from therespective purchase database (2500 or 2700) and presented to theapprover. This permits the approver to perform an ‘eyeball’ compare,i.e. human review, to ensure everything is correct prior to payment.This avoids the need for the approver to manually search for thepurchase document and manually retrieve it (which may be time consuming)prior to approval.

FIG. 69 is a block diagram of a server system 6900, including aneProcurement provider 20 hosted at server 3720. The server 3720 iscoupled, either locally or remotely, to a database/storage 3760 thathosts a plurality of databases, as previously described.

The electronic procurement (eProcurement) provider 20 interacts over anetwork 16 with a plurality of purchaser clients 212, both as describedearlier. The purchaser clients run client application 1532. TheeProcurement provider 20 also interacts over network 16 with a pluralityof supplier clients 214, wherein at least one of the suppliers has anassociated catalog, as described earlier. The supplier clients runclient application 1516. The supplier and client applications mayinclude a web-browser interface or a stand alone application foraccessing the eProcurement provider 20 and server 3720. The server 3720may provide a web interface 3750 as described earlier. The server 3720hosts a plurality of databases, as described earlier. The electronicprocurement provider 20 hosts one or more supplier and purchaserworkflow and material management 6902 applications, as describedearlier. These applications assist users 212 and suppliers 214 in makingtransactions using eProcurement provider 20, over the web interface.

In some embodiments, the electronic procurement system 20 is a singleinstance multi-tenant system. In some embodiments, the electronicprocurement system 20 is a web-based system, using web interface 3750.In some embodiments, the server 3720 is located independently fromsuppliers 214 and purchasers 212 of the electronic procurement system.

FIG. 70 shows an eProcurement system 7000 hosted at a supplier server7010, which interacts over a network 16 with a plurality of purchaserclients 212, both as described earlier. In this embodiment, the server7030 is located at a supplier 7010 of the electronic procurement system.The purchaser clients run client applications 1532. This application mayinclude a web-browser interface or a stand alone application, foraccessing the supplier electronic procurement service 7020 and server7030. The server 7030 may provide a web interface 7050 as describedearlier. The supplier server 7010 hosts a plurality of databases, asdescribed earlier. The supplier electronic procurement service 7020hosts one or more supplier workflow and material management 7010applications, as described earlier.

FIG. 71 shows an eProcurement system 7100 hosted at a purchaser server7110, which interacts over a network 16 with a plurality of supplierclients 214, wherein at least one of the suppliers has an associatedcatalog, as described earlier. In this embodiment, the server 7130 islocated at a purchaser 7110 of the electronic procurement system. Thesupplier clients run client application 1516. This application mayinclude a web-browser interface or a stand alone application, foraccessing the purchaser electronic procurement service 7120 and server7130. The server 7130 may provide a web interface 7150 as describedearlier. The purchaser server 7110 hosts a plurality of databases, asdescribed earlier. The purchaser electronic procurement service 7120hosts one or more supplier workflow and material management 7140applications, as described earlier.

FIG. 72 is a flowchart representing a server method 7200 for hosting aneProcurement system, according to certain embodiments of the invention.The server method 7200 may be governed by instructions that are storedin a computer readable storage medium, as described. In someembodiments, server method 7200 includes the following, performed atserver hosting an electronic procurement system.

One or more instructions for managing an invoice workflow are received(e.g. FIG. 59A workflow folder import browse button 5912, loadfolders/robots button 5914) (7202), wherein the instructions have one ormore steps having one or more rules (FIG. 59B, rules 5942 A-C), therules determining when a respective step is executed.

User commands are received 7204 to modify (FIG. 59B, steps 5931,activities 5940) instructions to generate a custom workflow having aplurality of steps (FIG. 59B, steps start 5943, stop 5944), with one ormore rules (associated with the plurality of steps).

The custom workflow is activated 7206 (in accordance with businessrules), such that the custom workflow is executed when an invoice isprocessed by the electronic procurement system (e.g., FIG. 59E matchingexception 5994 corresponds to a rule for matching exception 5943C inFIG. 59B).

In some embodiments, modifying instructions (i.e., commands or steps tomodify instructions) includes generating 7208 a rule for distributing anapproval workload to a plurality of approvers, wherein an approval taskassigned to a shared workflow folder (FIG. 59E, folder 5994) can bereviewed by any of a plurality of approvers. In some embodiments,distributing includes assigning a plurality of approvers to the sharedworkflow folder (7210).

In some embodiments, modifying instructions includes generating 7212 arule (e.g., FIG. 59B, rule 5943A) for processing an invoice notassociated with a purchase order. In some embodiments, modifyinginstructions includes generating 7214 a rule (e.g., FIG. 59B, rule5943B) for automatically matching an invoice to a purchase document. Insome embodiments, modifying instructions includes generating 7214 a rule(e.g., FIG. 59C, rule 5943B) for processing matching exceptions betweenan invoice to a purchase document. In some embodiments, modifyinginstructions includes generating 7214 a rule (e.g., FIG. 59D, rule5943B) for automatically approving an invoice for payment. In someembodiments, modifying instructions includes generating 7216 a rule forremoving (e.g., FIG. 59C, remove user 5972 and add user 5962) a user oran administrator from an invoice approval workflow.

In some embodiments, modifying instructions includes generating 7218 arule for displaying to an approver (e.g., FIG. 59C approvers 5966) aninvoice requiring approval. In some embodiments, the invoice is selected(7220) from a group consisting of a personal review folder and a sharedinvoice folder. In some embodiments, the one or more rules are defined(7222) by logical expressions (e.g., steps 5931, and rules 5943 A-D).

In some embodiments, the generated custom workflow is exported (7224) toa file (e.g., FIG. 59B, export 5926). This file may be an XML file, afile containing a markup language, a binary file, a text file, or a filewith any other format for storing data.

FIG. 73 is a flowchart representing a server method 7300 for hosting aneProcurement system, according to certain embodiments of the invention.The server method 7300 may be governed by instructions that are storedin a computer readable storage medium, as described. In someembodiments, server method 7300 includes the following, performed atserver hosting an electronic procurement system.

One or more instructions are received (7302) for managing an invoiceworkflow. At least part of the received instructions are activated(e.g., FIG. 59A, workflow imported instruction folder/robot 5914) (7304)such that the at least part of the activated instructions are executed(e.g., FIG. 59C invoice workflow approvals 5991, 5993, 5994) when aninvoice is processed by the electronic procurement system, wherein theactivating is performed in accordance with business rules.

In some embodiments, a rule is generated (7306) for distributing (e.g.,FIG. 59C approvers 5964 and users 5968) an approval workload to aplurality of approvers. In some embodiments, the distributing includesassigning (7308) a task to a shared workflow folder to be executed byany of the plurality of approvers.

FIG. 74 is a flowchart representing a server method 7400 for hosting aneProcurement system, according to certain embodiments of the invention.The server method 7400 may be governed by instructions that are storedin a computer readable storage medium, as described. In someembodiments, server method 7400 includes the following, performed atserver hosting an electronic procurement system.

A list of invoices requiring approval are sent (e.g., FIG. 59E, invoiceapprovals 5992) (7402) to a user of a system, wherein the list ofinvoices comprises one or more invoices assigned to a shared invoicefolder sent (e.g., FIG. 59E, window 5994 with shared approvers 5997)(5992) for which the user is an approver. In some embodiments, the listof invoices further comprises invoices assigned to a personal reviewfolder (e.g., FIG. 59E my invoice approvals 5993) associated with theuser (7404).

A command is received (7408) from the user to process (e.g., FIG. 59Eaction 5995, select 5996) one or more items selected from the list ofinvoices. In some embodiments, the command from the user comprises(7408) one selected from the group consisting of approve an invoice,complete an invoice, reject an invoice, place an invoice on hold, andforward an invoice to another approver. In some embodiments, the commandfrom the user includes assigning (7410) a substitute approver (e.g.,FIG. 59E assign 5998 approver) for a personal review folder associatedwith the user. In some embodiments, the command from the user includesassigning (7412) a substitute approver for the shared invoice folder.

In some embodiments, an item associated with one or more users isprocessed (7414) in response to a selection by a super user. In someembodiments, the processing comprises (7416) one selected from the groupconsisting of approve an invoice, complete an invoice, reject aninvoice, place an invoice on hold, and forward an invoice to anotherapprover.

In some embodiments, a task is assigned (7418) to a shared workflowfolder for review by any of a plurality of approvers, including theuser. In some embodiments, an approval status report is sent (7420) tothe user, showing at least one selected from the group consisting ofsubmission, approval, active and completed status (FIG. 59D, 5982, 5984,5986, 5988 respectively).

FIG. 75 includes a listing of folder and robots, including a Remit ToValidation folder 7502, a Non-PO Approvals folder 7504, a MatchingExceptions folder 7506, a Matching Exception folder 7508, and OverCredits folder 7510, an Auto-Matching folder 7512, an OK to Pay folder7514, and Over Credit-Auto Reject folder 7516, an Auto Match robot 7518,an Okay to Pay robot 7520, and an Over Credit/Invoice Process robot1800.

In some embodiments, the Remit To Validation folder 7502 confirms that asupplier address to which funds are remitted is a valid supplieraddress. In some embodiments, the supplier address associated with aninvoice is checked against a database of known supplier address (in someembodiments, controlled by a buyer administrator). Only if the addressassociated with the invoice matches with a known good supplier addressare funds remitted. This may prevent mistaken payments to incorrectsuppliers. This may also prevent unauthorized remittances of funds tounapproved suppliers, and thus help prevent fraud or misuse of theelectronic procurement system.

In some embodiments, the Non-PO Approvals folder 7504 implements anon-purchase order approval process, as described.

In some embodiments, the Matching Exceptions folder 7506 and MatchingException folder 7508 implement a matching exception(s) process, asdescribed.

In some embodiments, the Over Credits folder 7510 implements a processto prevent a supplier from over-crediting a returned item or items froma buyer. For example, a buyer may purchase ten units of a product, thenreturn the ten units to the supplier. If the supplier credits the buyerfor twelve units returned, then the supplier has over-credited the buyerby two units. The over credits folder 7510 identifies such a situationand flags it to an approver, in one embodiment by comparing the numberof returned items from a buyer against the number of credited items fromthe supplier.

In some embodiments, the Auto-Matching folder 7512 implements anautomatic matching process (e.g., between invoices and purchasedocuments), as described.

In some embodiments, the OK to Pay folder 7514, implements an approvalsystem for processing payment of invoices.

In some embodiments, the Over Credits Auto Reject folder 7516 implementsa process to prevent a supplier from over-crediting a returned item oritems from a buyer, and for automatically rejecting any invoices havingover credits.

In some embodiments, the Auto Match robot 7518, Okay to Pay robot 7520,and Over Credit/Invoice Process robot 1800 operate as described, eitheralone or in conjunction with the respective folder.

FIGS. 76A-76B illustrate an exemplary field management interface 10000in accordance with the present invention, as described. A LanguageSelection is illustrated, including a ‘select a language’ option forselecting a language for use in the electronic procurement system. AField Management selection is illustrated, allowing a user to selectfields from a field selection menu, showing a field history, and showingoptions for creating a new sibling or a new child. A ‘save option’ andan ‘apply all changes’ option is shown also.

FIGS. 77A-77C illustrate an exemplary update favorite(s) process flow10100 in accordance with the present invention, as described. An optionis provided for a user to select a favorite description, which may beapplied to a product, and which may be placed in a favorites menu.

FIGS. 78A-78B illustrate an exemplary document setup interface 10200 inaccordance with the present invention, as described. An option to addinternal attachments is shown. An option to add attachments for allsuppliers is shown.

FIG. 79 illustrates shows a system 10300 hosted at a supplier server10310, which interacts over a network 16 with a plurality of purchaserclients 212, both as described earlier. The purchaser clients run clientapplications 1532. This application may include a web-browser interfaceor a stand alone application, for accessing the supplier electronicprocurement service 10320 and server 10330. The server 10330 may providea web interface 10350 as describe earlier. The electronic procurementprovider 10320 hosts a plurality of databases 10360, including databases2200 as described earlier.

FIG. 80 illustrates shows a system 10400 hosted at a purchaser server10410, which interacts over a network 16 with a plurality of supplierclients 214, both as described earlier. The supplier clients run clientapplications 1516. This application may include a web-browser interfaceor a stand alone application, for accessing the purchaser electronicprocurement service 10420 and server 10430. The server 10430 may providea web interface 10450 as describe earlier. The electronic procurementprovider 10420 hosts a plurality of databases 10460, including databases2200 as described earlier.

In some embodiments, the electronic procurement system 20 is a singleinstance multi-tenant system. In some embodiments the electronicprocurement system 20 is a web-based system.

In some embodiments the electronic procurement system 20 is locatedindependently from suppliers and purchasers of the electronicprocurement system. In some embodiments the electronic procurementsystem 20 is located at a supplier of the electronic procurement system.In some embodiments the electronic procurement system 20 is located at apurchaser of the electronic procurement system.

Each of the above identified elements may be stored in one or more ofthe previously mentioned memory devices, and corresponds to a set ofinstructions for performing a function described above. The aboveidentified modules or programs (i.e., sets of instructions) need not beimplemented as separate software programs, procedures or modules, andthus various subsets of these modules may be combined or otherwisere-arranged in various embodiments. In some embodiments, memory 2010 and2110 may store a subset of the modules and data structures identifiedabove. Furthermore, memory 2010 and 2110 may store additional modulesand data structures not described above.

The foregoing description, for purpose of explanation, has beendescribed with reference to specific embodiments. However, theillustrative discussions above are not intended to be exhaustive or tolimit the invention to the precise forms disclosed. Many modificationsand variations are possible in view of the above teachings. Theembodiments were chosen and described in order to best explain theprinciples of the invention and its practical applications, to therebyenable others skilled in the art to best utilize the invention andvarious embodiments with various modifications as are suited to theparticular use contemplated.

What is claimed is:
 1. A computer-implemented method, comprising: at aserver hosting an electronic procurement system: in response toreceiving an invoice, identifying a purchase document corresponding tothe invoice; comparing contents of the purchase document to contents ofthe invoice; identifying a discrepancy between the purchase document andthe invoice; and generating a notification based upon the identifieddiscrepancy.